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.
>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.
> 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.
I 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.
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:
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.