Hi, Since there is no dedicated mailinglist for the RestBundle, I am continuing to use this list.
I have been reading some more, especially: http://dret.net/netdret/docs/soa-rest-icwe2009/design.pdf In this context I would like to bring up two topics: 1) Request Method handling In classic HTML(4) web applications we only differentiate between GET and POST. Usually our "create/edit" action has some code to determine if the user should wants the create/edit form or if the intention is to actually create/edit like the following: if ('POST' == $request->getMethod()) { .. if ($success) { new RedirectResponse(..); } } Now if we want to differentiate PUT from POST by using PUT exclusively for edit (idempotent) and POST exclusively for create this obviously doesn't work. Now since an "edit" requires a resource id as a parameter while a POST does not we often implement 2 separate methods. Meaning we have one createAction() and one editAction(). Now the problem is of course that a normal HTML(4) form cannot use PUT as the method, meaning that if we want to gracefully support HTML(4) form's while still being exact about the method in other cases we would have to write something like: if ('PUT' == $request->getMethod() ($format === 'html' && 'POST' == $request->getMethod()) ) { So I am pondering adding a method to the view layer to determine if the request method matches our expectations if ($view->checkRequestMethod('PUT')) 2) Error Handling Now Symfony2 internally tries to use the right HTTP status code for error conditions. However some are of course the job of the application developer. Some of this can be handled by the view layer. For example it will return a 415 when an unsupported format is requested. Others will usually be handled by an Exception like 404 via NotFoundHttpException. To help here I have added a custom ExceptionController that uses the view layer. Now where I am unsure is how to deal with some more specialized exceptions like a Doctrine OptimisticLockException. I would assume this would require returning a 409 (conflict). Now the question is how to best convert this OptimisticLockException into a 409, while making it easy for developers. So one approach could be of course to require the user Controller to handle this conversion, another could be to simply tell developers to let such Exceptions trickle trough to the ExceptionController that then does this mapping. We would then provide a useful list of mappings out of the box. regards, Lukas Kahwe Smith [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
