Am 04.03.2009 um 19:30 schrieb Bruce Keeler:
On 3/4/2009 4:45 AM, Moritz Onken wrote:
Furthermore I would not put the form rendering in the same path as
the
REST interface.
This is my preference too. Keep the browser stuff out of the REST
api.
I would do something like this:
# 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 /form/foo/<pk> -> edit record form
# GET /form/foo -> create record form
So now, what do we do with errors and redisplay of forms.
I would say a form should post / put / delete to the rest api.
Within that controller we can easily see if a browser is requesting
this url or a web service (see ForBrowser's looks_like_browser()).
If it's a browser we can detach to the /form/foo controller.
Otherwise we show the errors in the format of the Accept header.
I don't like this, however. If your UI is all AJAXy, by all means
let it use the REST api directly. But for old-school HTML forms,
I'd post to the /form/foo or /form/foo/<pk> and let that controller
either call the REST api internally, or bypass it altogether.
I like that idea!
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
