Skip to content

Routing and Rendering

Matching requests to controller actions is performed based on convention instead of extensive configuration.

There are 4 example routers included in our core library. They configure the Symfony router to perform the actual routing, so you can expect the same high performance.

After routing a request to the appropriate controller action, the router subsequently renders the response to ease controller testing:

Symlex\Router\Web\RestRouter handles REST requests (JSON)

Symlex\Router\Web\ErrorRouter renders exceptions as error messages (HTML or JSON)

Symlex\Router\Web\TwigRouter renders regular Web pages via Twig (HTML)

Symlex\Router\Web\TwigDefaultRouter is like TwigRouter but sends all requests to a default controller action (required for client-side routing e.g. with Vue.js)

Controller actions should not directly return JSON or HTML, but they can return Symfony Request objects e.g. to return binary data or to implement special use cases.

Default Routes

Below, you'll find a few examples based on our default configuration in App\Kernel\WebApp:

<?php

// The error router catches errors and displays them as error pages
$container->get('router.error')->route();

// Routing for REST API calls
$container->get('router.rest')
    ->route($this->getUrlPrefix('/api/v1'), 'controller.rest.v1.');

// All other requests are routed to a default controller action
$container->get('router.twig_default')
    ->route($this->getUrlPrefix(), 'controller.web.index', 'index');

// Uncomment the following line to enable server-side routing
// $container->get('router.twig')
//    ->route($this->getUrlPrefix(), 'controller.web.');

All request (except those starting with /api/v1) will be routed to controller.web.index service's indexAction(Request $request)

GET /api/v1/users will be routed to controller.rest.v1.users service's cgetAction(Request $request)

POST /api/v1/users will be routed to controller.rest.v1.users service's postAction(Request $request)

OPTIONS /api/v1/users will be routed to controller.rest.v1.users service's coptionsAction(Request $request)

GET /api/v1/users/123 will be routed to controller.rest.v1.users service's getAction($id, Request $request)

OPTIONS /api/v1/users/123 will be routed to controller.rest.v1.users service's optionsAction($id, Request $request)

GET /api/v1/users/123/comments will be routed to controller.rest.v1.users service's cgetCommentsAction($id, Request $request)

GET /api/v1/users/123/comments/5 will be routed to controller.rest.v1.users service's getCommentsAction($id, $commendId, Request $request)

PUT /api/v1/users/123/comments/5 will be routed to controller.rest.v1.users service's putCommentsAction($id, $commendId, Request $request)

If you uncomment router.twig in exchange for router.twig_default, requests (except those starting with /api/v1) will be routed to matching web controller actions e.g.:

GET / will be routed to controller.web.index service's indexAction(Request $request)

GET /foo will be routed to controller.web.foo service's indexAction(Request $request)

GET /foo/bar will be routed to controller.web.foo service's barAction(Request $request)

POST /foo/bar will be routed to controller.web.foo service's postBarAction(Request $request)

Development

It's easy to create your own custom routing based on our examples.

You should use a custom kernel in this case as your application's HTTP kernel is responsible for initializing routers and setting optional URL / service name prefixes.