RESTful Pharo app (not Seaside)

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

RESTful Pharo app (not Seaside)

Sean P. DeNigris
Administrator
What's the simplest/best way to communicate with a Pharo desktop app via RESTful API? Is anyone doing this? I frequently want to communicate with a running image and REST seems a little easier than XMLRPC which I've been using. I saw SimpleRestServer (http://forum.world.st/Simple-rest-server-td3571503.html), but was wondering if anyone has some good advice.

Thanks.
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

patmaddox
http://code.google.com/p/seaside/wiki/SeasideRest


On Oct 12, 2011, at 7:15 PM, Sean P. DeNigris wrote:

> What's the simplest/best way to communicate with a Pharo desktop app via
> RESTful API? Is anyone doing this? I frequently want to communicate with a
> running image and REST seems a little easier than XMLRPC which I've been
> using. I saw SimpleRestServer
> (http://forum.world.st/Simple-rest-server-td3571503.html), but was wondering
> if anyone has some good advice.
>
> Thanks.
> Sean
>
> --
> View this message in context: http://forum.world.st/RESTful-Pharo-app-not-Seaside-tp3900373p3900373.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

Sean P. DeNigris
Administrator
Thanks Pat. I was hoping not to have to load Seaside...
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

patmaddox
On Oct 13, 2011, at 8:30 AM, Sean P. DeNigris wrote:

>
> Pat Maddox-3 wrote:
>>
>> http://code.google.com/p/seaside/wiki/SeasideRest
>>
>
> Thanks Pat. I was hoping not to have to load Seaside...

Ah well then there's always Stout....super immature framework that James Ladd & I worked on in Vegas. I can upload what I have to Squeaksource a bit later if you want. You'll have to do some more work on it but it's a good starting point.

When I showed it at a lightning talk someone asked me if I had heard of Zinc, and said that it did something similar. Although when I looked I didn't see it... http://zn.stfx.eu/zn/index.html

Pat

Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

fstephany
In reply to this post by Sean P. DeNigris

> Thanks Pat. I was hoping not to have to load Seaside...

If your needs are simple you can maybe directly use Zinc ?

Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

Sean P. DeNigris
Administrator
fstephany wrote
If your needs are simple you can maybe directly use Zinc ?
Yes, I haven't played with Zinc yet, so this is a good opportunity. I read the "getting started" page and didn't see anything about REST. Where can I find Zinc REST examples or it is roll-your-own at this point?

Thanks.
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

NorbertHartl
In reply to this post by Sean P. DeNigris

Am 13.10.2011 um 17:30 schrieb Sean P. DeNigris:

>
> Pat Maddox-3 wrote:
>>
>> http://code.google.com/p/seaside/wiki/SeasideRest
>>
>
> Thanks Pat. I was hoping not to have to load Seaside...
>
The name Seaside-REST is a bit misleading because you need only little from seaside to get going. And there are no sessions and such created. I use it in production and I can say it is really easy to work with. Combined with the zinc lib you can have REST-like services _with_ proper mime handling data. Well, I put magritte and Magritte-XMLBinding on top and voila I have a full REST services with mime multipart handling and XML object serialization/deserialization without having to care too much about any of the involved components.
Soon I will add Magritte-JSON to it and will use the Accept header filtering provided by Seaside-REST and then all my wishes are fullfilled probably even before christmas this year.

Norbert




Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

Stéphane Ducasse
And norbert I would like you to present that to the next pharo conf. :)


On Oct 13, 2011, at 7:27 PM, Norbert Hartl wrote:

>
> Am 13.10.2011 um 17:30 schrieb Sean P. DeNigris:
>
>>
>> Pat Maddox-3 wrote:
>>>
>>> http://code.google.com/p/seaside/wiki/SeasideRest
>>>
>>
>> Thanks Pat. I was hoping not to have to load Seaside...
>>
> The name Seaside-REST is a bit misleading because you need only little from seaside to get going. And there are no sessions and such created. I use it in production and I can say it is really easy to work with. Combined with the zinc lib you can have REST-like services _with_ proper mime handling data. Well, I put magritte and Magritte-XMLBinding on top and voila I have a full REST services with mime multipart handling and XML object serialization/deserialization without having to care too much about any of the involved components.
> Soon I will add Magritte-JSON to it and will use the Accept header filtering provided by Seaside-REST and then all my wishes are fullfilled probably even before christmas this year.
>
> Norbert
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

Sven Van Caekenberghe
In reply to this post by Sean P. DeNigris
Sean, François,

On 13 Oct 2011, at 18:18, Sean P. DeNigris wrote:

> fstephany wrote:
>>
>> If your needs are simple you can maybe directly use Zinc ?
>>
>
> Yes, I haven't played with Zinc yet, so this is a good opportunity. I read
> the "getting started" page and didn't see anything about REST. Where can I
> find Zinc REST examples or it is roll-your-own at this point?
>
> Thanks.
> Sean

There is a Zinc-REST package in http://www.squeaksource.com/ZincHTTPComponents which depends on Zn only. I use this myself in a production project and it is my second version of this idea, but unfortunately it is not documented at all ;-)

The idea is that you plug a handler in a Zn server, an instance of ZnRestServerDelegate. This instance has a URI space. The URI space is another object that #match: -es a request to a call object, then the HTTP method of the call object is executed, with URI variables resolved by the matching process.

A concrete subclass of ZnRestUriSpace is ZnCallHierarchyRestUriSpace: here, a class hierarchy below some root represents the URI space. By subclassing the root from ZnAutoMatchedRestCall you can use a #pattern class method like #( 'users' '*") to match URIs like /users/12 (with 12 being the first variable). In very special cases, #match: itself can be overwritten.

So the hierarchy would be
 
ZnAutoMatchedRestCall
  MyRestCalls
    MyUsersRestCall

MyUsersRestCall class>>#pattern
        ^ #( 'users' '*")

MyUsersRestCall >>#get
        | user |
        user := MyUser userWithId: self variables first.
        ^ ZnResponse ok: (ZnEntity with: user asJson type: ZnMimeType applicationJson)

This is non-refactored code without error handling, but the idea should be clear.
I quite like it when each resouce has its own class, but some might like pragma's better.

Sven



Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

Stéphane Ducasse

On Oct 13, 2011, at 10:21 PM, Sven Van Caekenberghe wrote:

> Sean, François,
>
> On 13 Oct 2011, at 18:18, Sean P. DeNigris wrote:
>
>> fstephany wrote:
>>>
>>> If your needs are simple you can maybe directly use Zinc ?
>>>
>>
>> Yes, I haven't played with Zinc yet, so this is a good opportunity. I read
>> the "getting started" page and didn't see anything about REST. Where can I
>> find Zinc REST examples or it is roll-your-own at this point?
>>
>> Thanks.
>> Sean
>
> There is a Zinc-REST package in http://www.squeaksource.com/ZincHTTPComponents which depends on Zn only. I use this myself in a production project and it is my second version of this idea, but unfortunately it is not documented at all ;-)

well
we should document Zn first :)
Sven the first thing would be to produce some slides like that other people can read them and we could write a chapter for
Pharo for the enterprise.


> The idea is that you plug a handler in a Zn server, an instance of ZnRestServerDelegate. This instance has a URI space. The URI space is another object that #match: -es a request to a call object, then the HTTP method of the call object is executed, with URI variables resolved by the matching process.
>
> A concrete subclass of ZnRestUriSpace is ZnCallHierarchyRestUriSpace: here, a class hierarchy below some root represents the URI space. By subclassing the root from ZnAutoMatchedRestCall you can use a #pattern class method like #( 'users' '*") to match URIs like /users/12 (with 12 being the first variable). In very special cases, #match: itself can be overwritten.
>
> So the hierarchy would be
>
> ZnAutoMatchedRestCall
>  MyRestCalls
>    MyUsersRestCall
>
> MyUsersRestCall class>>#pattern
> ^ #( 'users' '*")
>
> MyUsersRestCall >>#get
> | user |
> user := MyUser userWithId: self variables first.
> ^ ZnResponse ok: (ZnEntity with: user asJson type: ZnMimeType applicationJson)
>
> This is non-refactored code without error handling, but the idea should be clear.
> I quite like it when each resouce has its own class, but some might like pragma's better.
>
> Sven
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

Sean P. DeNigris
Administrator
Thanks for all the responses. I'm reminded how great our community is. Also, REST is working out beautifully as a simple cross-language communication channel since every language and even the command line can send/receive via http. Straight XMLRPC felt like it was in my way by comparison.

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

NorbertHartl
In reply to this post by Stéphane Ducasse

Am 13.10.2011 um 22:07 schrieb Stéphane Ducasse:

> And norbert I would like you to present that to the next pharo conf. :)
>
deal!

Norbert

>
> On Oct 13, 2011, at 7:27 PM, Norbert Hartl wrote:
>
>>
>> Am 13.10.2011 um 17:30 schrieb Sean P. DeNigris:
>>
>>>
>>> Pat Maddox-3 wrote:
>>>>
>>>> http://code.google.com/p/seaside/wiki/SeasideRest
>>>>
>>>
>>> Thanks Pat. I was hoping not to have to load Seaside...
>>>
>> The name Seaside-REST is a bit misleading because you need only little from seaside to get going. And there are no sessions and such created. I use it in production and I can say it is really easy to work with. Combined with the zinc lib you can have REST-like services _with_ proper mime handling data. Well, I put magritte and Magritte-XMLBinding on top and voila I have a full REST services with mime multipart handling and XML object serialization/deserialization without having to care too much about any of the involved components.
>> Soon I will add Magritte-JSON to it and will use the Accept header filtering provided by Seaside-REST and then all my wishes are fullfilled probably even before christmas this year.
>>
>> Norbert
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: RESTful Pharo app (not Seaside)

NorbertHartl
In reply to this post by Sven Van Caekenberghe

Am 13.10.2011 um 22:21 schrieb Sven Van Caekenberghe:

> Sean, François,
>
> On 13 Oct 2011, at 18:18, Sean P. DeNigris wrote:
>
>> fstephany wrote:
>>>
>>> If your needs are simple you can maybe directly use Zinc ?
>>>
>>
>> Yes, I haven't played with Zinc yet, so this is a good opportunity. I read
>> the "getting started" page and didn't see anything about REST. Where can I
>> find Zinc REST examples or it is roll-your-own at this point?
>>
>> Thanks.
>> Sean
>
> There is a Zinc-REST package in http://www.squeaksource.com/ZincHTTPComponents which depends on Zn only. I use this myself in a production project and it is my second version of this idea, but unfortunately it is not documented at all ;-)
>
> The idea is that you plug a handler in a Zn server, an instance of ZnRestServerDelegate. This instance has a URI space. The URI space is another object that #match: -es a request to a call object, then the HTTP method of the call object is executed, with URI variables resolved by the matching process.
>
> A concrete subclass of ZnRestUriSpace is ZnCallHierarchyRestUriSpace: here, a class hierarchy below some root represents the URI space. By subclassing the root from ZnAutoMatchedRestCall you can use a #pattern class method like #( 'users' '*") to match URIs like /users/12 (with 12 being the first variable). In very special cases, #match: itself can be overwritten.
>
> So the hierarchy would be
>
> ZnAutoMatchedRestCall
>  MyRestCalls
>    MyUsersRestCall
>
> MyUsersRestCall class>>#pattern
> ^ #( 'users' '*")
>
> MyUsersRestCall >>#get
> | user |
> user := MyUser userWithId: self variables first.
> ^ ZnResponse ok: (ZnEntity with: user asJson type: ZnMimeType applicationJson)
>
> This is non-refactored code without error handling, but the idea should be clear.
> I quite like it when each resouce has its own class, but some might like pragma's better.
>
Did you have a look at Seaside-REST. I think Phillipe did a great job in implementing the routing for http handlers. As far as I know the whole routing code is not seaside dependent at all. It is just the way to enable it. Would probably useful to have a look there and try to phase out the seaside stuff and enable it to adapt to different things like zinc.

What do you mean?

Norbert