Providing REST api
Locked
 
|
How do you handle situations where Seaside app needs to provide REST
api to some other system, or framework? There seem at least 2 types of such situations: a) some foreign sytem like credit card processor, or such, needs to call some url on your site and collect feedback. So this call is not necessary releated to some Seaside session, but it needs to poke around the database that is used by Seaside app. b) Javascript widget that you use in your seaside app, like for instance datatables, needs to make ajax calls to your server to fetch some session related data, and url needs to anser for instance json list of particular client orders. What is the best way to handle such situations in your experience? Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
This includes the seaside-REST stuff which might be of use to you:
http://www.squeaksource.com/Seaside30Addons.html
On Mon, Dec 27, 2010 at 12:06 PM, Davorin Rusevljan <[hidden email]> wrote: How do you handle situations where Seaside app needs to provide REST _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Very interesting, I didn't know about this package and I'm coding my own REST apis by hand... is there an example or documentation somewhere?
Cheers, Esteban El 27/12/2010, a las 2:15p.m., Sean Allen escribió: This includes the seaside-REST stuff which might be of use to you: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Providing REST api
|
|
In reply to this post by drush66
The best way is your way. You can just use the #initialRequest: that is going to be received by your app. Once you have that, you're done to do whatever you want in your app's logic. You can take advantage of something more general, but in practice, so far I din't found it necessary On Dec 27, 2010, at 3:06 PM, Davorin Rusevljan wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by EstebanLM
There is some documentation somewhere, I can't find it. PM could probably point you in
the correct direction as he wrote the Seaside-Rest stuff.
On Mon, Dec 27, 2010 at 1:10 PM, Esteban Lorenzano <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by EstebanLM
2010/12/27 Esteban Lorenzano <[hidden email]>:
> Very interesting, I didn't know about this package and I'm coding my own > REST apis by hand... is there an example or documentation somewhere? Yes there is [1]. There is also Magritte-Json [2] to automatically generate JSON from your models, just hurry before Lukas takes the server offline. You can find examples here [3] All that stuff hasn't been used in anger. [1] http://code.google.com/p/seaside/wiki/SeasideRest [2] http://source.lukas-renggli.ch/magritteaddons.html [3] http://seaside.gemstone.com/ss/CouchDB.html Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by sebastianconcept@gmail.co
2010/12/27 Sebastian Sastre <[hidden email]>:
> The best way is your way. > You can just use the #initialRequest: that is going to be received by your > app. If you don't go on and use the component in infrastructure (#renderContentOn:, …) this isn't really ideal. In the worst case you create a session that isn't ever used again. If you don't need the component infrastructure just using a RequestHandler or RequestFilter is probably the better solution. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Providing REST api
|
|
Isn't seaside overkill at that point?
I mean, if you don't use the component infrastructure what else seaside is going to help you with? maybe sessions or tasks? (not that APIs don't have those, still...) On Dec 27, 2010, at 8:08 PM, Philippe Marschall wrote: > 2010/12/27 Sebastian Sastre <[hidden email]>: >> The best way is your way. >> You can just use the #initialRequest: that is going to be received by your >> app. > > If you don't go on and use the component in infrastructure > (#renderContentOn:, …) this isn't really ideal. In the worst case you > create a session that isn't ever used again. If you don't need the > component infrastructure just using a RequestHandler or RequestFilter > is probably the better solution. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
not if most of your application is a serious seaside app but you need to provide restful access to parts of it.
which from my reading was what the OP had in mind.
On Mon, Dec 27, 2010 at 5:58 PM, Sebastian Sastre <[hidden email]> wrote: Isn't seaside overkill at that point? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by sebastianconcept@gmail.co
2010/12/27 Sebastian Sastre <[hidden email]>:
> Isn't seaside overkill at that point? > > I mean, if you don't use the component infrastructure what else seaside is going to help you with? Not at all. You can still use your familiar request and response objects without locking yourself to a server or dialect, you still have the templating engine should you need it, you can still use the application/configuration infrastructure. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Providing REST api
|
|
Yeah but none of those is an incredible competitive advantage either.
What I would found interesting tough, is to use seaside where it shines: managing complex state. Think of the facebook API or twitter or whatever API that needs to manage authentication, session expiration, persisted stuff, etc All things that your fully visual seaside webapp does only in a non-visual version (just with requests). That would be: 1. seriously valuable 2. a common need Wonder if tasks can be used to control state and flux of a non visual app. What would they #call: ? On Dec 28, 2010, at 6:57 AM, Philippe Marschall wrote: > 2010/12/27 Sebastian Sastre <[hidden email]>: >> Isn't seaside overkill at that point? >> >> I mean, if you don't use the component infrastructure what else seaside is going to help you with? > > Not at all. You can still use your familiar request and response > objects without locking yourself to a server or dialect, you still > have the templating engine should you need it, you can still use the > application/configuration infrastructure. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2010/12/28 Sebastian Sastre <[hidden email]>:
> Yeah but none of those is an incredible competitive advantage either. > > What I would found interesting tough, is to use seaside where it shines: managing complex state. > Think of the facebook API or twitter or whatever API that needs to manage authentication, session expiration, persisted stuff, etc > All things that your fully visual seaside webapp does only in a non-visual version (just with requests). > > That would be: > > 1. seriously valuable > 2. a common need > > Wonder if tasks can be used to control state and flux of a non visual app. > > What would they #call: ? Well, that would certainly be doable but it would not be REST at all. You'd use components/tasks that create XML or JSON which includes the action URL and fields names (think AtomPub or HATEOAS). The client would then have to parse the response for the action URL and the callback names. Maybe you also want a specialized action phase continuation that does not redirect. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Providing REST api
|
|
Yeah, I've also questioned that it wouldn't be REST. But... so what? What matters is to get the thing done. You can make the app seem REST (accidentally) just to make it more familiar to people implementing clients but do the think the way you know you can capitalize best. So, yeah right? you can have those components that render XML (or JSON). And that idea about preventing the redirect, I like that. Given the chance it will be fun to play with this On Dec 28, 2010, at 8:46 AM, Philippe Marschall wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2010/12/28 Sebastian Sastre <[hidden email]>:
> Yeah, I've also questioned that it wouldn't be REST. > But... so what? > What matters is to get the thing done. You can make the app seem REST > (accidentally) just to make it more familiar to people implementing clients > but do the think the way you know you can capitalize best. > So, yeah right? you can have those components that render XML (or JSON). Yeah, just override #rendererClass like RSRSS does. > And > that idea about preventing the redirect, I like that. Just subclass WAActionPhaseContinuation and change #shouldRedirect to answer false. You probably also need a custom WARenderPhaseContinuation that does not create an HtmlRoot > Given the chance it will be fun to play with this The trickiest part is probably the action URLs and callbacks. You can certainly make it work but it might require some ugly copy/paste code. I might have time to hack something xml-based together. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2010/12/28 Philippe Marschall <[hidden email]>:
> 2010/12/28 Sebastian Sastre <[hidden email]>: >> Yeah, I've also questioned that it wouldn't be REST. >> But... so what? >> What matters is to get the thing done. You can make the app seem REST >> (accidentally) just to make it more familiar to people implementing clients >> but do the think the way you know you can capitalize best. >> So, yeah right? you can have those components that render XML (or JSON). > > Yeah, just override #rendererClass like RSRSS does. > >> And >> that idea about preventing the redirect, I like that. > > Just subclass WAActionPhaseContinuation and change #shouldRedirect to > answer false. You probably also need a custom > WARenderPhaseContinuation that does not create an HtmlRoot > >> Given the chance it will be fun to play with this > > The trickiest part is probably the action URLs and callbacks. You can > certainly make it work but it might require some ugly copy/paste code. > I might have time to hack something xml-based together. Seaside-WebServices-Core and Seaside-Tests-WebServices from [1]. There is WASampleXmlComponent in the tests that demonstrates #call:, #answer: and callbacks. It's a bit clunky has no client but works. [1] http://www.squeaksource.com/Seaside30Addons Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Providing REST api
|
|
Oh wonderful, we have a starting point!
On Dec 28, 2010, at 2:45 PM, Philippe Marschall wrote: > 2010/12/28 Philippe Marschall <[hidden email]>: >> 2010/12/28 Sebastian Sastre <[hidden email]>: >>> Yeah, I've also questioned that it wouldn't be REST. >>> But... so what? >>> What matters is to get the thing done. You can make the app seem REST >>> (accidentally) just to make it more familiar to people implementing clients >>> but do the think the way you know you can capitalize best. >>> So, yeah right? you can have those components that render XML (or JSON). >> >> Yeah, just override #rendererClass like RSRSS does. >> >>> And >>> that idea about preventing the redirect, I like that. >> >> Just subclass WAActionPhaseContinuation and change #shouldRedirect to >> answer false. You probably also need a custom >> WARenderPhaseContinuation that does not create an HtmlRoot >> >>> Given the chance it will be fun to play with this >> >> The trickiest part is probably the action URLs and callbacks. You can >> certainly make it work but it might require some ugly copy/paste code. >> I might have time to hack something xml-based together. > > Seaside-WebServices-Core and Seaside-Tests-WebServices from [1]. There > is WASampleXmlComponent in the tests that demonstrates #call:, > #answer: and callbacks. It's a bit clunky has no client but works. > > [1] http://www.squeaksource.com/Seaside30Addons > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2010/12/29 Sebastian Sastre <[hidden email]>:
> Oh wonderful, we have a starting point! The next thing you might probably want is that the requests can be XML or JSON instead of url-encoded and the callbacks are extracted from there. You might also want a JSON canvas. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Providing REST api
|
|
I think I just found the first application for this: making worker images talk one each other in the backbone
Everything in the farm has to be async and without points of contention but there are some maintenance tasks that require coordination and would be nice to see them negotiating one with each other to find dynamically when is the best moment to do it. I.e. when the active number of users are below x or something like that. Like a restaurant you know... after certain hour, when there is just those 2 customers left, you can tell the janitor that he can start to do its job alright :) On Dec 29, 2010, at 4:02 PM, Philippe Marschall wrote: > 2010/12/29 Sebastian Sastre <[hidden email]>: >> Oh wonderful, we have a starting point! > > The next thing you might probably want is that the requests can be XML > or JSON instead of url-encoded and the callbacks are extracted from > there. > > You might also want a JSON canvas. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |