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