Aside from the obvious answer of "Best Practice" and "Creates a Standard" is there a technical argument for using GET, POST, PUT, DELETE, etc. instead of doing everything with POST?
Asked
Active
Viewed 107 times
2
-
One reason is that the url should identify what you're talking *about*, so that "get that employee" and "update that employee" doesn't require two distinct endpoints. – Lasse V. Karlsen Oct 09 '18 at 16:39
-
They could do that with different VERBS, less confusing verbs if that was the only reason. I mean take PUT vs PATCH as a confusing example. – Rodney S. Foley Oct 09 '18 at 16:53
3 Answers
2
In addition to creating a Uniform Interface, the different verbs have different properties:
safe (GET, HEAD, OPTIONS, TRACE)
The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm.
idempotent (PUT, DELETE, GET, HEAD, OPTIONS, TRACE)
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response.
cacheable: (GET, HEAD, POST)
Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse;
All the intermediate servers that make up "the internet" rely on the uniform interface and those properties to work correctly. That includes Content Delivery Networks, proxies, and caches. Using verbs correctly helps the internet work better.
Community
- 1
- 1
Eric Stein
- 13,209
- 3
- 37
- 52
0
Those verbs are part of the HTTP specification which is a primary reason we use them when we do REST over HTTP, and it was in the early days we started doing REST over HTTP so they became part of the best practice.
Rodney S. Foley
- 10,190
- 12
- 48
- 66
-
RFC 2616 has been obsolete since 2014. Please reference RFCs 7230-7235 for the updated HTTP/1.1 specifications. – Eric Stein Oct 09 '18 at 16:55
-
It was the first hit I found and it explained the verbs correctly regardless. I removed it anyways as it doesn't impact the answer. – Rodney S. Foley Oct 09 '18 at 16:58
0
is there a technical argument for using GET, POST, PUT, DELETE, etc. instead of doing everything with POST?
Yes.
In the case of HTTP, one of the important reasons to choose GET over POST is caching. RFC 7234 defines a bunch of caching semantics that can be written into messages (specifically into the headers).
One of the interesting problems of computer science is cache invalidation; in HTTP, there is a specific semantic for invalidation that is related to methods:
A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.
In other words, part of the distinction between POST and GET (also HEAD), is that generic clients know to invalidate cached representations of resources. So I can use a third party headless browser to talk to your API, and caching "just works".
The lines between POST and the other unsafe methods are less clear, but present. The basic outline is that POST can mean anything - but PUT and DELETE both specifically describe idempotent operations. So once again, I don't need to customize a client that does the right thing if messages are being lost on the unreliable network -- I can use a domain agnostic HTTP client to PUT and DELETE, and rebroadcast of lost messages can again "just work".
The power of the distinctions between methods is that we can create and re-use generic intermediate components (headless browsers, caches, reverse proxies) that know HTTP semantics, and (because we've described our domain protocols using those semantics) they all "just work" -- the generic components are able to do useful work even through they have no idea what is really going on.
Community
- 1
- 1
VoiceOfUnreason
- 52,766
- 5
- 49
- 91