2014-10-02 10:19 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
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.
Exactly!
GET (and HEAD) should be idempotent, so two identical GET requests shouldn't cause any resource/server state modification. [1]
That's not true. It should not modify the resource identified by the URI. But is still possible to have side effects. Otherwise a GET request that produces a line in a logfile would be impossible, right?
You're right, but generally speaking logging is orthogonal to the resource itself.
And btw. all verbs are idempotent except PATCH and POST.
Strictly speaking also true, but two *identical* DELETE requests to the same URI will first return a 200 and then a 404. Also two *identical* PUT request with a version identifier (sort of MVCC) will succeed the first time and fail the second. This is more a matter of convention. I'm not a REST purist myself. But certain HTTP client libraries, particularly for mobile, can request (or even submit) more than once. Regards, Esteban A. Maringolo