Why do we need anything more than HTTP GET, PUT, POST?

Question

What is the practical benefit of using HTTP GET, PUT, DELETE, POST, HEAD? Why not focus on their behavioral benefits (safety and idempotency), forgetting their names, and use GE

Answer 1

In a word:

idempotency

In a few more words:

GET = safe + idempotent

PUT = idempotent

DELETE = idempotent

POST = neither safe or idempotent

'Idempotent' just means you can do it over and over again and it will always do exactly the same thing.

You can reissue a PUT (update) or DELETE request as many times as you want and it will have the same effect every time, however the desired effect will modify a resource so it is not considered 'safe'.

A POST request should create a new resource with every request, meaning the effect will be different every time. Therefore POST is not considered safe or idempotent.

Methods like GET and HEAD are just read operations and are therefore considered 'safe' aswell as idempotent.

This is actually a pretty important concept because it provides a standard/consistent way to interpret HTTP transactions; this is particularly useful in a security context.

Answer 2

No one posted the kind of answer I was looking for so I will try to summarize the points myself.

"RESTful Web Services" chapter 8 section "Overloading POST" reads: "If you want to do without PUT and DELETE altogether, it’s entirely RESTful to expose safe operations on resources through GET, and all other operations through overloaded POST. Doing this violates my Resource-Oriented Architecture, but it conforms to the less restrictive rules of REST."

In short, replacing PUT/DELETE in favor of POST makes the API harder to read and PUT/DELETE calls are no longer idempotent.

Answer 3

Web applications using GET and POST allow users to create, view, modify and delete their data, but do so at a layer above the HTTP commands originally created for these purposes. One of the ideas behind REST is a return to the original intent of the design of the Web, whereby there are specific HTTP operations for each CRUD verb.

Also, the HEAD command can be used to improve the user experience for (potentially large) file downloads. You call HEAD to find out how large the response is going to be and then call GET to actually retrieve the content.

Answer 4

See the following link for an illustrative example. It also suggests one way to use the OPTIONS http method, which hasn't yet been discussed here.

Answer 5

Why do we need more than POST? It allows data to flow both ways, so why would GET be needed? The answer is basically the same as for your question. By standardizing the basic expectations of the various methods other processes can better know what to do.

For example, intervening caching proxies can have a better chance of doing the correct thing.

Think about HEAD for instance. If the proxy server knows what HEAD means then it can process the result from a previous GET request to provide the proper answer to a HEAD request. And it can know that POST, PUT and DELETE should not be cached.

Answer 6

HEAD is really useful for determining what a given server's clock is set to (accurate to within the 1 second or the network round-trip time, whichever is greater). It's also great for getting Futurama quotes from Slashdot:

~$ curl -I slashdot.org
HTTP/1.1 200 OK
Date: Wed, 29 Oct 2008 05:35:13 GMT
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.005001227
X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank.
Cache-Control: private
Pragma: private
Connection: close
Content-Type: text/html; charset=iso-8859-1

For cURL, -I is the option for performing a HEAD request. To get the current date and time of a given server, just do

curl -I $server | grep ^Date