Zbigniew Lukasiak wrote on 03/03/2009 04:18 PM: > On Tue, Mar 3, 2009 at 10:27 PM, Peter Karman <[email protected]> wrote: >> Zbigniew Lukasiak wrote on 03/03/2009 02:53 PM: >> >>>> If you use CatalystX::CRUD::REST, you can do: >>>> >>>> # POST /foo -> create new record >>>> # GET /foo -> list all records >>>> # PUT /foo/<pk> -> update record >>>> # DELETE /foo/<pk> -> delete record >>>> # GET /foo/<pk> -> view record >>>> # GET /foo/<pk>/edit_form -> edit record form >>>> # GET /foo/create_form -> create record form >>>> >>>> CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of >>>> 'x-tunneled-method' param to support PUT and DELETE via POST. >>> And where do the forms submit? I mean what is their action address? >>> Do they submit to themselves - or does edit_form submit to >>> /foo/<pk>?x-tunneled-method=PUT and create to /foo both with POST >>> method? And it is the second - then what do you do when the form >>> parameters are incorrect and you need to redisplay the form? >> using the CXC REST API: >> >> if you GET /foo/1234, then you must PUT /foo/1234 to save it. >> (or POST /foo/1234?x-tunneled-method=PUT -- although I always put the >> x-tunneled-method value in a hidden input body param, not as part of the >> URL). > Sure - that was just for clarification of how the PUT is done with browsers :) > > >> if you GET /foo/create_form, then you must POST /foo. >> >> When the form is redisplayed on validation error, it just retains the >> original action. > > I was just thinking about the possible CRUD REST schemas and it found > that under that schema you display the same form under two addresses: > /foo/1234/edit_form and /foo/1234 (in case of the error). And the > other day I had that idea that perhaps instead of using path part - > use another parameter so /foo/1234?x-view-method=edit_form would > render the form and /foo/1234 would render the standard view of the > object. This way the form would have just one address. >
In CXC REST, /foo/1234 is analogous to /foo/1234/view in the RPC format. It does not return a HTML form. It just returns the object data. I.e., read-only. So the URLs represent two different things. Of course, that's just how I implement the API in CatalystX::CRUD::YUI, but you could make /foo/1234 return whatever you want. The basic API is view-agnostic, and there's nothing in the core Controller API that dictates what is returned. The controllers just stash the object represented by the URL and leave representation up to the view. > Both things are just different representations of the same thing - so > using a parameter to differentiate between them seems quite logical. > But on the other hand it might look too different from the traditional > ways. > > they could be different (as they are in CXC::YUI), or they could be the same. That's up to the implementer of the API, I guess. -- Peter Karman . [email protected] . http://peknet.com/ _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
