I’ve trying a lot on this but no avail.

Regards,
Sab

Client:

    // Iterate over datatable's aoData and build an
    //  object with named properties.
    var oData = {};
    $.each(aoData,function(){
        oData[this.name]=this.value;
    });
 
    //Then, iterate over addn'l params, add to data
    $.each(codeParams,function(){oData[this.name]=this.value;});
 
    // Create DTO (receivable as Dictionary <string,object>
    var DTO = {'p':oData};
 
    //POST json to server
    $.post(svcpath+method,JSON.stringify(DTO),fnCallback);

WebMethod:

    [WebMethod(Description = "Returns one page of data for the Drawings grid (DataTables.net format")]
    [ScriptMethod(ResponseFormat = ResponseFormat.Json)]
    public DataTablesList getDrawingDT(Dictionary<string, object> p)
    {
        System.Web.HttpContext context = System.Web.HttpContext.Current;
        context.Response.ContentType = "application/json";
         switch ((string) p["nodeType"])
         {
          ...

So, I’m good now! :-) Thanks for your help, Dave, I really appreciate it!

As for working with DataTables, you can use $.ajaxSetup to influence how its AJAX calls work. If what you’ve got it working though, I wouldn’t fix what isn’t broken.

The primary reason that ASP.NET services force POST access is for security. When you allow GET requests, a third-party site can potentially make requests for your services using your users’ credentials (via the auth/session cookies that are automatically transmitted with any HTTP request) when they happened to unsuspectingly visit a malicious site. If the data you’re displaying isn’t particularly sensitive, it’s probably safe to not worry about the GET vs. POST distinction. Many would argue that GET is more appropriate for idempotent read-only requests anyway – we only use POST with ASP.NET services to enable the nice JSON support.

 
        /*
         * Ordering
         */
        string sOrder = "";
        if (context.Request["iSortCol_0"] != null)
        {
            sOrder = "ORDER BY  ";
            for (int i = 0; i < Int32.Parse(context.Request["iSortingCols"]); i++)
            {
                string iSortCol = context.Request["iSortCol_" + i.ToString()];
                string mDataProp = context.Request["mDataProp_" + iSortCol];
                string sSortDir = context.Request["sSortDir_" + i.ToString()];
                if (context.Request["bSortable_" + iSortCol] == "true")
                {
                    sOrder += aSortColumns[Array.IndexOf(aColumns, mDataProp)] + " " + sSortDir + ", ";
                }
            }
            sOrder = sOrder.TrimEnd(new char[] { ' ', ',' });
        }
        if (sOrder == "ORDER BY" || sOrder == "") sOrder = " ORDER BY " + idcol + " ";

However, I’m just wondering if there’s a way to do similar using a POST, since that’s ASP.NET default. But first, does it even matter? Is there anything “bad” about using GET instead of POST for a WebMethod? Secondly, is there any way to design a receiving class that ASP.NET can automagically map the parameters to, without knowing ahead of time what parameters will be sent?

If it bothers you, you can return an anonymous type to get rid of it:

public object GetPerson(int ID) {
  Person p = new Person(ID);
 
  return new {
    FirstName = p.FirstName,
    LastName = p.LastName,
    // Etc
  }
}

For collections, you can use LINQ to objects to pull out an IEnumerable collection of anonymous objects.

Should I use a library like JSON.NET on the server side to serialize the complex type object and pass it back to the client using a string return type on the service method?

instead of { [ blah : foo }, { blah3 : foo }] }

I’m not sure why you’d go out of your way to abandon the automatic JSON handling that WCF and ASMX offer though. If you reinvent that wheel, you’re basically just writing an HttpHandler. Why use WCF at all?

So if wanted to set up a WCF service that didn’t use ASP.NET Ajax Endpoint, I would instead use a basicHttpBinding with behavior and some serializer on the server side like Atlas, AjaxPro or JSON.NET. When doing it this way, the return types on all service methods would always be string, right? What would the mime-type be set to then?

On the client side then, all I’d have to do is set the dataType to “json” and it’ll do all the work for me

If you’re using jQuery 1.4+ and aren’t stripping the .d, neither the dataFilter or json2.js are necessary for parsing the incoming response.