Am 02.10.2014 um 14:56 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-10-02 7:57 GMT-03:00 phil@highoctane.be <phil@highoctane.be>:
Too bad I live in a retared telecom-wise and mobile-competition wise country.
You're not alone.
Esteban A. Maringolo
ps: It is funny they use GET to send a message. :)
I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something.
Putting authentication in headers is also better, because it is more orthogonal.
In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference.
In REST speak you have to see that there are two types of resources. A resource that represents the resource identified by the URI (itself) and a processing resource that takes the content and produces something else. For HEAD, PUT and DELETE this is the former type. POST is always the latter. And here the "creation of a new resource below the collection" is just a convention not a necessity. The case for GET is that it serves both use cases. They acquire a resource from the URI regardless if it is the entity in the URI or the processing entity. The problem with GET API method seems to be that they are produced by lazy/inexperienced developers. The benefit of GET URLs is that you can put them in a mail. The whole REST approach leaves us alone with a use case like a confirmation mail. Same goes for GET requests containing a body. my 2 cents, Norbert