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.
>

>
> 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
>
>
>
>

> 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

> 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 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
>>
>>
>>
>>
>
>

> 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.
>