SOAP and HTTP GET and POST

SOAP and HTTP GET and POST : a perfect world spoiled by reality

Home
IBM
developerWorks
alphaWorks
Koinonia
God's Book
My (lesser known) Book

SOAP and HTTP GET and POST

All of the recent discussion about when, where and how to use HTTP GET and POST with SOAP has led me to go back and reevaluate the use of SOAP over HTTP and the use of the various core HTTP operations.

First, let's look at the core HTTP 1.1 operations....

Operation	Description
OPTIONS	"Represents a request for information about the communication options available on the request/response chain identified by the Request-URI". In Web Services, this could be interpreted as a request for the WSDL description of the Service.
GET	"The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process."
HEAD	"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response"
POST	"The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line"
PUT	"The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server."
DELETE	"The DELETE method requests that the origin server delete the resource identified by the Request-URI."
TRACE	"The TRACE method is used to invoke a remote, application-layer loop- back of the request message."
CONNECT	"This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel"

Looking these over, there are a couple of things to consider. First, the "resource" identified by the HTTP Request URI is the Web Service itself, not the data that the Web service deals with. The Web Service is a data-producing resource.

That said, a SOAP HTTP GET operation implies a request for the Web Service to produce a SOAP message. (Example 1)

Example 1: SOAP HTTP GET operation
Request
GET /StockQuoteService?symbol=IBM HTTP/1.1
Host: www.ibm.com
Response
HTTP/1.1 200 OK
Content-Type: application/soap-xml; charset="utf-8"
Content-Length: nnnn
<env:Envelope>...</env:Envelope>

The HTTP POST operation is a bit strange when it comes to Web services, but based on the language used to describe the POST operation semantics within the HTTP specification, it is extremely clear that the use of POST for a RPC invocation is clearly very wrong. That said, other than GET, there is no other core HTTP Operation that can be used for RPC invocations, therefore, I would go so far as to propose a new HTTP method called "INVOKE".

The INVOKE operation indicates that the operation indicated by the HTTP data entity (the SOAP Envelope) should be invoked against the Web service indicated by the URI. If the INVOKE operation results in a response SOAP Envelope, the HTTP server should respond with a 200 OK response that contains the resulting SOAP envelope. If no response SOAP Envelope is created, the HTTP server should respond with a 204 No Content response.

Example 2: SOAP HTTP INVOKE operation
Request
INVOKE /StockQuoteService HTTP/1.1
Host: ww.ibm.com
Content-Type: application/soap-xml; charset="utf-8"
Content-Length: nnnn
<env:Envelope>...</env:Envelope>
Response
HTTP/1.1 200 OK
Content-Type: application/soap-xml; charset="utf-8"
Content-Length: nnnn
<env:Envelope>...</env:Envelope>

Going through this process, we see a number of interesting side effects of applying the various HTTP core operations to Web services.

For example, the PUT and DELETE operations actually map to the deployment and undeployment of Web services. In other words, when you do a "DELETE" against a URI that indicates a Web service, the Web service should be deleted. When you do a "PUT" against a URI, the Web service is deployed.

The OPTIONS HTTP method would probably be best for returning the WSDL description for a Web Service since the WSDL is what would be used to express the communication options for the Web Service.

The bottom line is, I'm starting to agree that using HTTP POST for SOAP RPC invocations is not the proper approach. Creating a new INVOKE operation would be.