[Seaside] Providing REST api

[Sebastian Sastre]

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

sebastian

o/


On Dec 28, 2010, at 8:46 AM, Philippe Marschall wrote:

> 2010/12/28 Sebastian Sastre <sebastian at flowingconcept.com>:
>> 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
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20101228/e1139c24/attachment.htm