Sending SMS through Pharo/HTTP
Hi, The Free french telecom company introduces a new feature that allow sending SMS to your own mobile phone using a HTTP query All you need is to activate the option at no cost, and use Pharo. Have fun :-) ZnEasy get: 'https://smsapi.free-mobile.fr/sendmsg?user=YourLogin&pass=YourPassword&msg=H...' Noury
Too bad I live in a retared telecom-wise and mobile-competition wise country.â I am jealous. Alternative ways? Like using Google that sends free SMS for Google Calendar. Phil
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. Sven
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] 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.
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? 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.
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. 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.
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 <mailto: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.
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
FTI, as a complement, here is the web site where I found all the information about doing a SMS Gateway : http://domotique-info.fr/2014/01/un-script-python-comme-serveur-sms/ (french) https://translate.google.fr/translate?hl=fr&sl=auto&tl=en&u=http%3A%2F%2Fdom... Several parts can be done un smalltalk ... but using a NAS Synology, I'm quite forced to use Python (at least on the NAS) but once the bridge is done to use web request, one could use Pharo tu use the SMS Server. Still not happy with the PHP part though... Cheers, Cédrick 2014-10-02 16:40 GMT+02:00 Cédrick Béler <cdrick65@gmail.com>:
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
-- Cédrick
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
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
Tropo.com has free developer accounts. I've made an interface to their WebAPI that allows you to send & receive SMS messages and telephone calls from Pharo, GemStone, and, last time I checked, Squeak. The code is here: http://smalltalkhub.com/#!/~pdebruic/Tropo beware the 'About Tropo' info at that page is outdated as it no longer uses Kom but Zinc. Tropo does work internationally, and allows you to have a belgian (or whereever) phone number. Their list of countries is https://www.tropo.com/docs/scripting/international-features/international-di... philippeback wrote
Too bad I live in a retared telecom-wise and mobile-competition wise country.â
I am jealous. Alternative ways? Like using Google that sends free SMS for Google Calendar.
Phil
-- View this message in context: http://forum.world.st/Sending-SMS-through-Pharo-HTTP-tp4781988p4782113.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 02 Oct 2014, at 12:16, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi,
The Free french telecom company introduces a new feature that allow sending SMS to your own mobile phone using a HTTP query All you need is to activate the option at no cost, and use Pharo. Have fun :-)
ZnEasy get: 'https://smsapi.free-mobile.fr/sendmsg?user=YourLogin&pass=YourPassword&msg=H...'
Noury
That is cool, indeed. I would write it as ZnClient new url: 'https://smsapi.free-mobile.fr/sendmsg'; queryAt: #user put: 'YourLogin'; queryAt: #pass put: 'YourPass'; queryAt: #msg put: 'Hi From Pharo'; get. The Percent Encoding and query building is then done for your. Sven
thanks Sven for the example, and more importantly for Zinc :-) On 02 Oct 2014, at 14:21, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 02 Oct 2014, at 12:16, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi,
The Free french telecom company introduces a new feature that allow sending SMS to your own mobile phone using a HTTP query All you need is to activate the option at no cost, and use Pharo. Have fun :-)
ZnEasy get: 'https://smsapi.free-mobile.fr/sendmsg?user=YourLogin&pass=YourPassword&msg=H...'
Noury
That is cool, indeed.
I would write it as
ZnClient new url: 'https://smsapi.free-mobile.fr/sendmsg'; queryAt: #user put: 'YourLogin'; queryAt: #pass put: 'YourPass'; queryAt: #msg put: 'Hi From Pharo'; get.
The Percent Encoding and query building is then done for your.
Sven
participants (7)
-
Cédrick Béler -
Esteban A. Maringolo -
Norbert Hartl -
Noury Bouraqadi -
Paul DeBruicker -
phil＠highoctane.be -
Sven Van Caekenberghe