Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

language tweaks

  • Loading branch information...
1 parent cf3e22b commit aec3e0699f1bde957be862827c6c7494fc00b208 @lsmith77 lsmith77 committed
13 Resources/doc/
@@ -2,13 +2,12 @@ Step 3: Listener support
-are a way to hook into the REST handling of
-a request and in the preparation of a response to send back. The hooks in view relate
-to getting things from the request (parameter fetcher listener), doing some processing
-with the payload gotten from a request (body listener), formatting the response either
-with a template engine like twig or to json format or xml via the serializer (format
-listener), and finally also how to affect the response like in the previous listener
-but in things relating to the view (view response listener).
+are a way to hook into the request handling. The this Bundles provides various events
+from decoding the request content in the request (body listener), determining the
+correct response format (format listener), reading parameters from the request
+(parameter fetcher listener), to formatting the response either with a template engine
+like twig or to f.e. xml or json using a serializer (view response listener)) as well
+as automatically setting the accepted http methods in the response (accept listener).
With this in mind we now turn to explain each one of them.
4 Resources/doc/
@@ -1,8 +1,8 @@
Step 4: ExceptionController support
-When implementing a secured REST API you would want to block requests by firing
-exceptions with default or custom information back to the client. This bundle
+When implementing an API it is also necessary to handle exceptions in a RESTful
+way, while ensuring that no security sensitive information leaks out. This bundle
provides an extra controller for that job. Using this custom ExceptionController
it is possible to leverage the View layer when building responses for uncaught
9 Resources/doc/
@@ -22,10 +22,9 @@
Single RESTful controller routes
-Single as opposed to multiple is just the focus of our routes, that is whether they are referring
-to just one resource without subresources or to resources that have subresources. The resource
-routes in the second case is described a bit different and is seen in the next section. Now we
-turn to simple resource routes.
+In this section we are looking at controllers for resources without sub-resources.
+Handling of sub-resources requires some additional considerations which
+are explained in the next section.
# app/config/routing.yml
@@ -39,7 +38,7 @@ Notice ``type: rest`` option. It's required so that the RestBundle can find whic
Notice the ``name_prefix: my_bundle_`` option. It's useful to prefix the generated controller routes to organize
your several resources paths. Take care that you can use ``name_prefix`` on an import only when the file is imported
-itself with the type ``rest``. The parent option is used in subresources as we will see in the next section for
+itself with the type ``rest``. The parent option is used in sub-resources as we will see in the next section for
multiple RESTful controller routes.
## Define resource actions

0 comments on commit aec3e06

Please sign in to comment.
Something went wrong with that request. Please try again.