locked
Calling ServiceOperation with POST Paramaters RRS feed

  • Question

  • Hi,

     I am able to call my ADO.NET Data Service ServiceOperation with an JQuery .ajax() call but the paramaters I pass are always null.

    I am trying to use HTTP POST ... I added [WebInvoke] to the method and have even tried [WebInvoke(Method = "POST")] and [WebInvoke(Method = "*")]

    When I switch to a normal HTTP GET and pass my parameters exactly the same way with the JQuery .ajax() call the paramaters are passed properly and everything works.

     

    Are there limitations to how posts work in ServiceOperations? I am using .NET 3.5 SP1 with the latest update.

     

    Here is an example of my Jquery call:


    var serviceUrl = ODataService + '/AuthenticateUser';


            $.ajax({
                type: "POST",
                url: serviceUrl,
                contentType: "application/json; charset=utf-8",
                data: "{'email': ''" + emailVal + "'','password': ''" + passwordVal + "''}",
                dataType: "json",
                success: callback
            });

     

     

    Any help would be greatly appreciated

    Thanks

    Mike

    • Edited by Miskiw Thursday, May 6, 2010 5:15 PM
    Wednesday, May 5, 2010 1:53 PM

Answers

  • Unfortunately WCF Data Services does not support reading paramters from the request body at the moment. Appending parameters to the URL for POST requests is valid as per HTTP rules but I agree that this does not have that much value since in this case there is not much difference between such a POST message and that GET message that would do the same.

    It would be interesting to know your particular scenario - for create profile - why don't you just POST Profile entity to the service?

    Pawel

    • Marked as answer by Miskiw Thursday, May 6, 2010 5:31 PM
    Thursday, May 6, 2010 5:14 PM

All replies

  • I believe you have to send the parameters in the URI rather than in the request body.

    Pawel

    Wednesday, May 5, 2010 4:59 PM
  • If that is true then this is by definition an HTTP GET and not an HTTP POST. I am basically hunting to see if that is actual how the service operations work (GET Only). I need to pass a large series of values in some calls (Create Profile for example) and might run out of room in the url length (which has a limited length).

     

     

     

    Wednesday, May 5, 2010 5:13 PM
  • Well... I still can't get the value to come through in the ServiceOperation method parameters.

    BUT

    My solution to allow HTTP POST is now is to use HttpContext.Current.Request.Form[KeyName] which does actually contain the values I posted.

    This code is rather unfortunate:

            [WebInvoke]
            public IQueryable<User> AuthenticateUser(string email, string password)
            {
                if (string.IsNullOrEmpty(email) && HttpContext.Current.Request.Form.AllKeys.Contains("email"))
                {
                    email = HttpContext.Current.Request.Form["email"] as string;
                }

                if (string.IsNullOrEmpty(password) && HttpContext.Current.Request.Form.AllKeys.Contains("password"))
                {
                    password= HttpContext.Current.Request.Form["password"] as string;
                }


                if (string.IsNullOrEmpty(email) || string.IsNullOrEmpty(password))
                {
                    throw new DataServiceException("Please supply a valid Email Address and Password");
                }
            

                return CurrentDataSource.AuthenticateUser(email, password);
            }

     

     

    This has to be a bug ??

    Thursday, May 6, 2010 5:08 PM
  • Unfortunately WCF Data Services does not support reading paramters from the request body at the moment. Appending parameters to the URL for POST requests is valid as per HTTP rules but I agree that this does not have that much value since in this case there is not much difference between such a POST message and that GET message that would do the same.

    It would be interesting to know your particular scenario - for create profile - why don't you just POST Profile entity to the service?

    Pawel

    • Marked as answer by Miskiw Thursday, May 6, 2010 5:31 PM
    Thursday, May 6, 2010 5:14 PM
  • My particular scenario is a little unorthodox for a OData Feed really... We have data that suites the "atom feed" format nicely which we have in the feed but there are just a few operations that we wanted to tack onto the service for utility purposes and these were mainly our user profile calls.

    We do not have a Entity Set for "Users" we just have a few calls that return single items:
    Authenticate  User, Update User and Create User just so external applications can inject new users from their applications.

    Maybe we should have broken those calls into a different service.. but that just another url we have to maintain and hand out... which is why we are just trying to jam it into our main service.

    In theory I suppose the OData way of doing things would be to have an "Users" Entity Set and allow for values to be "GET/POST/PUT" against that set. But our data is all custom and coming from legacy stored procedures.

     

    At least my HttpContext.Current.Request.Form[KeyValue] is working for now.. would just be nice if my paramaters were properly populated/mapped by WCF data services.

     

    Thanks for the help

     

    Thursday, May 6, 2010 5:29 PM
  • Oh also.. POST-ing the data in the query string of the url does work as advertised ... but is there a max length imposed on the length of the "URL"?

     

     

    Thursday, May 6, 2010 5:40 PM
  • Hi,

    The URL length is usually limitted by the host (that is the web server, like IIS). But in general tehre is a limit and it is somewhat short. You can overcome that by using $batch requests which usually have much larger limit on the URLs of the particular requests.

    Thanks,


    Vitek Karas [MSFT]
    Thursday, May 6, 2010 10:41 PM
    Moderator
  • Using service operations seems reasonable given that you have some legacy system that is internally using stored procedures. If you need to pass more data than allowed by GET you can follow Vitek's advise and send batch requests. Finally if you really would like to dive in Data Services you may try implementing your own provider that will expose Users as entity set and will internally call corresponding stored procedures for POST/PUT/MERGE requests. It's not a trivial task though. Here is a series of blog articles that show how to do that: http://blogs.msdn.com/alexj/archive/tags/DSP/default.aspx

    Pawel

    Friday, May 7, 2010 4:10 PM
  • You can overcome that by using $batch requests which usually have much larger limit on the URLs of the particular requests.

     

    However we face with System.Uri limit in this case (64Kib)

    Saturday, May 14, 2011 2:57 PM