Hi all, This is actually doable to use a POST request instead of a GET. ZnClient new url: 'https://smsapi.free-mobile.fr/sendmsg'; queryAt: #user put: '12345'; queryAt: #pass put: 'sqsdqsfzedfqsd'; queryAt: #msg put: 'Hi again From Pharo é@è!§'; post. Tested OK. BTW, I'm using a GSM modem with Gnokii deamon to use it as a SMS server on a NAS Synology. The problem with the smsapi proposed before is that it can only send to your mobile and it has a dependance on the internet connection. This is a more universal option, but then it's far more tricky to interface. I right now use a script in python to expose a "webservice" url so send message... But I need a better way to do it (my aim is to be able to have a communication channel other than email so that I can send group message, query and treat responses (YES NO...)). Cheers, Cédrick 2014-10-02 15:34 GMT+02:00 Norbert Hartl <norbert@hartl.name>:
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â¦"
Norbert
But yes, it is more about design, not about what is forbidden, it is about conventions. The whole HTTP design is a bit unclear.
And btw. all verbs are idempotent except PATCH and POST.
Norbert
Esteban A. Maringolo
[1] We all now Seaside also breaks this rule by design (hence its "heretic" tagline), and there isn't any foreseeable way of changing this to comply with HTTP recommended usage.
-- Cédrick