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.
Bruce
_______________________________________________
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/
