4 ms·
I humbly submit that using PUT is wrong. Argument follows, citing wording at http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols
by jholman 12y ago
I humbly submit that using PUT is wrong. Argument follows, citing wording at
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
First of all, we're not "enclosing" an "entity" to be "stored" or "accepted", so neither HTTP verb is strictly appropriate.
PUT requests are for uploading a resource, and the uploader specifies the desired final URL. So PUT is only appropriate for creating a new horn. Relevant quotation:
In contrast [with POST], the URI in a PUT
request identifies the entity enclosed with
the request -- the user agent knows what URI
is intended and the server MUST NOT attempt
to apply the request to some other resource.
If the server desires that the request be
applied to a different URI, it MUST send a
301 (Moved Permanently) response; the user
agent MAY then make its own decision
regarding whether or not to redirect the request.
POST requests, by contrast, are sent to a handling resource, which decides what to do. POST is appropriate for several purposes, including "annotating existing resources" and "providing ... data ... to a data-handling process". Seems like a better fit.
But either way, REST is for documents (understood broadly), and I don't think I know how to understand "document" broadly enough to cover a horn. So it's gonna be a rough stretch, and in general, I'm skeptical about the value of applying REST semantics.
- sambe 12y agoDoesn't it depend on the level of abstraction you see? The URI of the horn is known. The document is { remainingDuration: 1 }.
- noonespecial 12y ago>But either way, REST is for documents (understood broadly), and I don't think I know how to understand "document" broadly enough to cover a horn. So it's gonna be a rough stretch, and in general, I'm skeptical about the value of applying REST semantics. That's probably about the wisest thing that's going to be posted on the subject tonight. I did a large enunciator panel project and we ended up being "rest-ish", using the idempotent PUT to put hardware dodads into various states, and reserving POST for adding things to execution queues. Being clear and consistent is probably the silver pearl in any implementation. Hardware control always degrades to some kind of RPC scheme, even if you dress it in a REST outfit.
- marcosdumay 12y ago> I'm skeptical about the value of applying REST semantics. One must at least take the basic protocol promises into account. And there is no certainty that a GET will reach its destination, nor that it (or a PUT) will reach destination only once.
- jholman 12y agoI agree absolutely; if you're using HTTP, you must take into account HTTP semantics. Exactly as you said. But HTTP is not REST (note that SOAP usually layers over HTTP, although the SOAP-vs-REST is an unhelpful dichotomy). As some other commenters (including an uncle of this comment) have said, what one often wants is simply RPC, and one must pick (or roll) an RPC format. JSON-or-whatever over HTTP seems good to me, and yes one must be respectful of HTTP semantics. In fact, aside from the very-troubling choice of GET for commands, the API linked seems entirely reasonable. And it's not RESTful at all (in ways far deeper than verb choice). And that's a good thing.