RESTful Pharo app (not Seaside)
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.
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.
Pat Maddox-3 wrote:
Thanks Pat. I was hoping not to have to load Seaside... -- View this message in context: http://forum.world.st/RESTful-Pharo-app-not-Seaside-tp3900373p3901889.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On Oct 13, 2011, at 8:30 AM, Sean P. DeNigris wrote:
Pat Maddox-3 wrote:
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
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 -- View this message in context: http://forum.world.st/RESTful-Pharo-app-not-Seaside-tp3900373p3902074.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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
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
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 -- View this message in context: http://forum.world.st/RESTful-Pharo-app-not-Seaside-tp3900373p3902821.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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
Am 13.10.2011 um 17:30 schrieb Sean P. DeNigris:
Pat Maddox-3 wrote:
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
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:
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
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:
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
participants (6)
-
Francois Stephany -
Norbert Hartl -
Pat Maddox -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe