RE: Issue 133, and permitting no body

>Heh.  Well, linked off our home page is this;
>which includes some discussion about why GET is so special to 
>web architecture.

GET is absolutely special and furthermore, I would claim that it is
important for scalability and robustness that there be as few ways as
possible of expressing a safe and idempotent request. Note that it is
possible to have such requests decorated with access control, payment
mechanisms, privacy control etc. without affecting their fundamental
property of being safe and idempotent.

Although HTTP can support an open-ended set of requests (GET, POST,
DELETE, etc.) it really is optimized for GET. However, as you mention,
it is not the only protocol that supports GET, and inherently there is
no reason why SOAP could not have a general GET message type rather than
thousands of getX and getY message types. I think "Give me a
representation of yourself" applies just as well to SOAP resources as to
any other resource, especially as SOAP does inherit many properties from

By taking out the SOAP body as a means of indicating that a SOAP message
is safe and idempotent, you seem to propose that the body inherently is
unsafe. I don't think this is necessarily the case - as has been
discussed, a query is often safe and idempotent and seems to fit nicely
within a SOAP body.

Being able to serialize such a SOAP message in a URI seems like a good
thing and if so the mapping to HTTP GET is straight forward. Rather than
removing the body, however, one could potentially provide a schema for
the body that any safe and idempotent SOAP message type could derive


Received on Friday, 1 February 2002 01:22:28 UTC