Sending SMS through Pharo/HTTP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Sending SMS through Pharo/HTTP

Noury Bouraqadi-2
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: '<a href="https://smsapi.free-mobile.fr/sendmsg?user=YourLogin&amp;pass=YourPassword&amp;msg=Hi From Pharo'">https://smsapi.free-mobile.fr/sendmsg?user=YourLogin&pass=YourPassword&msg=Hi%20From%20Pharo'

Noury

Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

philippeback
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
Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Sven Van Caekenberghe-2
In reply to this post by Noury Bouraqadi-2

On 02 Oct 2014, at 12:16, Noury Bouraqadi <[hidden email]> 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=Hi%20From%20Pharo'
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Esteban A. Maringolo
In reply to this post by philippeback
2014-10-02 7:57 GMT-03:00 [hidden email] <[hidden email]>:
> 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. :)

Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

philippeback
SMS is 160, which fits a query string.​
Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Noury Bouraqadi-2
In reply to this post by Sven Van Caekenberghe-2
thanks Sven for the example, and more importantly for Zinc :-)

On 02 Oct 2014, at 14:21, Sven Van Caekenberghe <[hidden email]> wrote:

>
> On 02 Oct 2014, at 12:16, Noury Bouraqadi <[hidden email]> 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=Hi%20From%20Pharo'
>>
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Sven Van Caekenberghe-2
In reply to this post by Esteban A. Maringolo

On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> wrote:

> 2014-10-02 7:57 GMT-03:00 [hidden email] <[hidden email]>:
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Esteban A. Maringolo
2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

NorbertHartl
In reply to this post by Sven Van Caekenberghe-2

> Am 02.10.2014 um 14:56 schrieb Sven Van Caekenberghe <[hidden email]>:
>
>
> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> wrote:
>
>> 2014-10-02 7:57 GMT-03:00 [hidden email] <[hidden email]>:
>>> 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


Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

NorbertHartl
In reply to this post by Esteban A. Maringolo

> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <[hidden email]>:
>
> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Sven Van Caekenberghe-2

On 02 Oct 2014, at 15:19, Norbert Hartl <[hidden email]> wrote:

>>
>> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <[hidden email]>:
>>
>> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>>> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Esteban A. Maringolo
In reply to this post by NorbertHartl
2014-10-02 10:19 GMT-03:00 Norbert Hartl <[hidden email]>:

>
>> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <[hidden email]>:
>>
>> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>>> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

NorbertHartl
In reply to this post by Sven Van Caekenberghe-2

Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <[hidden email]>:


On 02 Oct 2014, at 15:19, Norbert Hartl <[hidden email]> wrote:


Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <[hidden email]>:

2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

cedreek
Hi all,

This is actually doable to use a POST request instead of a GET. 

ZnClient new
  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 <[hidden email]>:

Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <[hidden email]>:


On 02 Oct 2014, at 15:19, Norbert Hartl <[hidden email]> wrote:


Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <[hidden email]>:

2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

cedreek
FTI, as a complement, here is the web site where I found all the information about doing a SMS Gateway :



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 <[hidden email]>:
Hi all,

This is actually doable to use a POST request instead of a GET. 

ZnClient new
  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 <[hidden email]>:

Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <[hidden email]>:


On 02 Oct 2014, at 15:19, Norbert Hartl <[hidden email]> wrote:


Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <[hidden email]>:

2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
On 02 Oct 2014, at 14:40, Esteban A. Maringolo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Sending SMS through Pharo/HTTP

Paul DeBruicker
In reply to this post by philippeback
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-dialing-sms



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