locked
Using WCF Data Service Operations with JSON string parameters RRS feed

  • Question

  • We are developing a browser based application that will use jquery on the client to communicate with a WCF Data Service on a server. We would like to use service operations to perform all CRUD functions by passing JSON serialized data graphs.  Prior to creating the browser based UI, I am using a console application to do some testing.

    During my testing however, I am running into a problem with the MaxQueryString limit when I serialize a large data graph and use it as a parameter to a WCF Data Service operation for modifying the data.

    My first question is whether or not this is a good approach, ie. using service operations for CRUD rather than creating ODATA urls that specify the CRUD actions.?

    If it is a reasonable approach, what is the largest string that I can use as a parameter?  I am testing using IIS Express and have specified an extremely large MaxQueryString limit (as large as 100,000) in my web.config file, but this did not fix the issue since the error message continued to complain about MaxQueryString.  The error however was somewhat different when I specified MaxQueryString to be 12,000 than when it was specified as 100,000.


    Al G.

    Monday, April 22, 2013 11:05 PM

Answers

  • In general it is better to use OData native operations (PUT/POST/DELETE) to perform CRUD instead of service operations. It's more "OData"-like and supports entire entities as input.

    Service operations have rather limited set of inputs. Only primitive types can be passed in and their size is limited by what can fit into one URL. Lot of servers limit the URL sizes. In fact it's not just servers but proxies and so on. So trying to use really long URLs usually leads to trouble. (There's also a limit in .NET itself, which I think is 64K of characters).

    In OData V3 you could use Actions, which are like service operations, but they can take parameters in the payload body and thus don't run into the URL length limits. They also allow complex parameters (not just primitives). See for example: http://blogs.msdn.com/b/astoriateam/archive/2011/10/17/actions-in-wcf-data-services.aspx. They still don't allow entities as input though (at least not in WCF DS implementation).

    All in all, in the order of recommendation:

    - Native HTTP verbs - POST, PUT, DELETE, ...

    - Actions

    - Service operations

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by RentAPlace Monday, April 29, 2013 12:46 PM
    Tuesday, April 23, 2013 6:46 PM
    Moderator

All replies

  • In general it is better to use OData native operations (PUT/POST/DELETE) to perform CRUD instead of service operations. It's more "OData"-like and supports entire entities as input.

    Service operations have rather limited set of inputs. Only primitive types can be passed in and their size is limited by what can fit into one URL. Lot of servers limit the URL sizes. In fact it's not just servers but proxies and so on. So trying to use really long URLs usually leads to trouble. (There's also a limit in .NET itself, which I think is 64K of characters).

    In OData V3 you could use Actions, which are like service operations, but they can take parameters in the payload body and thus don't run into the URL length limits. They also allow complex parameters (not just primitives). See for example: http://blogs.msdn.com/b/astoriateam/archive/2011/10/17/actions-in-wcf-data-services.aspx. They still don't allow entities as input though (at least not in WCF DS implementation).

    All in all, in the order of recommendation:

    - Native HTTP verbs - POST, PUT, DELETE, ...

    - Actions

    - Service operations

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by RentAPlace Monday, April 29, 2013 12:46 PM
    Tuesday, April 23, 2013 6:46 PM
    Moderator
  • Thanks for the feedback.  I have subsequently found that most browsers have an even more restrictive url max length limit of about 2k.  We will be looking at different ways to accomplish what we want.

    Al G.

    Monday, April 29, 2013 12:50 PM