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