Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <
sven@stfx.eu>:
On 02 Oct 2014, at 15:19, Norbert Hartl <norbert@hartl.name> wrote:
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?
Nothing you said is wrong (including your other mail), but for us, a log service where a GET would add data would not fly, that would definitively have to be a POST.
Sure. I don't think we need to argue here because we would mostly agree on all those things. I just wanted to clarify my point by providing a simple example. The log I meant is that of a frontend web server like apache, that adds a line to a log file even on GET request. Just food for thought about a statement "���shouldn't cause any resource/server state modification���"