Wire format (HTTP) for AJAX JSON Requests in different frameworks?

I am trying to find out more low-level details on the HTTP requests that various JS/AJAX frameworks create when sending JSON POST requests to the web server. I am looking most importantly for information on the following f开发者_如何学JAVArameworks (but info about any other notable exceptions is appreciated): .net, jquery, prototype, DWR and MooTools.

What I want to know is, when these frameworks make calls to different "methods" on the server, what (in the HTTP request) differentiates the different method calls? So far I have seen the following:

1. The URL differentiates the method calls, i.e. "POST /app/s.svc/method1 HTTP/1.1" versus "POST /app/s.svc/method2 HTTP/1.1" etc.
2. The URL is the same for different method calls, but an HTTP header differentiates the method calls, i.e. "X-AjaxPro-Method: method1" versus "X-AjaxPro-Method: method2" etc.

Are there other examples of "multiplexing" method calls to the same URL other than with HTTP headers? Does the JSON itself ever contain the method name, without an indication in the HTTP headers, like a SOAP method that is contained only within the SOAP:Body, without a corresponding "SOAPMethodName" header? Are there any other cases that I haven't though of?

Thanks for your help.

In HTTP you don't address methods you address resources. Looking at it from a Framework independent view the HTTP Specification offers three main Methods namely GET, POST, PUT and DELETE on a resource (lets say http://example.com/users/2 which is a user with the id 2). The software architectural style behind this idea of resources and the uniform Interface of these four methods is called REST.

If you follow this architectural style there are many frameworks that can work with it and it uses the HTTP protocol as it is supposed to (sending X-AjaxPro-Method in the header is definitely not HTTP standard compliant).

While the current trend is towards REST over HTTP and RESTful services, it sounds like what you're looking for an RPC mechanism. If that is the direction you want, you should probably take a look at JSON-RPC. It's an RPC mechanism so it's a lot closer to SOAP or XML-RPC than REST.