4 ms·
The issue this piece exposes is much wider than REST and completely independent of the validity/desirability of REST. The semantics of PUT and POST are defined
by aGHz 15y ago
The issue this piece exposes is much wider than REST and completely independent of the validity/desirability of REST. The semantics of PUT and POST are defined in the HTTP spec, a much lower level than the architectural one at which REST exists. As such, everyone developing HTTP-enabled code SHOULD (RFC 2119) obey the proper semantics to make sure we all use the same vocabulary. I mean, c'mon guys, there's only a handful of verbs!
This is HTTP not REST. You need to understand this even if you're against REST.
(edited to remove tl;dr. It looked much longer in my text box)
- artsrc 15y agoWhat parts of REST can you be against if you are ok with HTTP. If REST is the architecture that HTTP is an protocol for can you really use HTTP properly without understanding REST?
- NanoWar 15y agoYou could do XML-RPC over HTTP. You could do SOAP over HTTP. Those would be rather RESTless.
- artsrc 15y agoI really don't think SOAP is very ok with HTTP. It misuses the protocol and subverts its goals. For example, version 1 used POST for safe, idempotent requests.
- aGHz 15y agoThe biggest one is encoding state exclusively in the hypertext communication (what many people would call statelessness). Most web devs aren't comfortable doing away with sessions, but that's just fine as far as HTTP cares.