I'm designing an API to go over HTTP and I am wondering if using the HTTP POST command, but with URL query parameters only and no request body, is a good way to go.
Considerations:
- "Good Web design" requires non-idempotent actions to be sent via POST. This is a non-idempotent action.
- It is easier to develop and debug this app when the request parameters are present in the URL.
- The API is not intended for widespread use.
- It seems like making a POST request with no body will take a bit more work, e.g. a
Content-Length: 0header must be explicitly added. - It also seems to me that a POST with no body is a bit counter to most developer's and HTTP frameworks' expectations.
Are there any more pitfalls or advantages to sending parameters on a POST request via the URL query rather than the request body?
Edit: The reason this is under consideration is that the operations are not idempotent and have side effects other than retrieval. See the HTTP spec:
In particular, the convention has beenestablished that the GET and HEADmethods SHOULD NOT have thesignificance of taking an action otherthan retrieval. These methods ought tobe considered "safe". This allows useragents to represent other methods,such as POST, PUT and DELETE, in aspecial way, so that the user is madeaware of the fact that a possiblyunsafe action is being requested.
...
Methods can also have the property of"idempotence" in that (aside fromerror or expiration issues) theside-effects of N > 0 identicalrequests is the same as for a singlerequest. The methods GET, HEAD, PUTand DELETE share this property. Also,the methods OPTIONS and TRACE SHOULDNOT have side effects, and so areinherently idempotent.