POST vs GET

[McEniry, Michael]

HTTP POST with application/x-www-form-urlencoded parameters is not equivalent to GET, notably due to the caching advantages of GET. A lot of server-side toolkits provide equivalent handling of parameter for both methods, which is especially convenient when the distinctions are not important, but this can confuse matters.

The RFC seems to omit which methods must not include an entity in the request, although it does indicate that some exist <http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3>: "A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request."

One trick we've used to avoid extra long GET URIs is to have one of the parameters be an indirection to another URI (eg, w3c's validator <http://validator.w3.org/check?uri=http%3A%2F%2Fvalidator.w3.org%2F>) or to a special token (a stateful no-no, web-architecture-wise, but there are mitigations available). An example of the latter that might be relevant to DAP is to have a DAP server that supports user-defined functions (stored procedures). A suitably authorized client might POST or PUT a function definition to the DAP server. Then subsequent GET requests could use that function by name.