Home » Php » php – How to display the symfony profiler for API request made in the browser?

php – How to display the symfony profiler for API request made in the browser?

Posted by: admin April 23, 2020 Leave a comment


I’m developing a REST api with Symfony2 + FOSRest bundle.

I would like to know if there is any way for a call to the api in dev mode (app_dev.php) from the browser (corresponding to a Accept: text/html,application/xhtml+xml header) to display the response in the “specified format”, wrapped in html with the profiler provided by symfony.

It would allow to debug calls to the api directly in the browser.

I don’t want to debug the HTTP request but the whole process (route matching, DB queries involved, etc). That’s why I want to have access to the symfony profiler.

How to&Answers:

Since Symfony 2.4, the profiler sets two additional settings in the HTTP header: X-Debug-Token and X-Debug-Token-Link. (see http://symfony.com/blog/new-in-symfony-2-4-quicker-access-to-the-profiler-when-working-on-an-api)

These headers contain the token and the direct link to the profiler for the current request. They are always sent if the profiler is enabled.

Not surprisingly, there is already an extension available for Chrome, that checks for the existence of these headers and provide extra information: Symfony2 Profiler shortcut

In my opinion, this is better than any custom html-wrapper, but this only works for GET and maybe POST requests – PUT and DELETE requests are a bit trickier. There you can use a http client, like the chrome-extension POSTMAN and open the profiler manually by opening the link provided in the http-header X-Debug-Token-Link or keep your profiler-page (f.e. http://example.org/_profiler/) opened.


The reason the WebDebugToolbar isn’t displayed when developing a JSON or XML API is that the toolbar is set to only be injected into HTML-type responses.

To overcome this you could add a kernel.response Event Listener in your Bundle which converts your JSON or XML responses into HTML.

namespace Acme\APIBundle\Event\Listener;

use Symfony\Component\HttpKernel\Event\FilterResponseEvent;

class ConvertToHtmlResponse {
  public function onKernelResponse(FilterResponseEvent $event) {
    if (!$event->isMasterRequest()) {

    $request = $event->getRequest();

    // Only send back HTML if the requestor allows it
    if (!$request->headers->has('Accept') || (false === strpos($request->headers->get('Accept'), 'text/html'))) {

    $response = $event->getResponse();
    switch ($request->getRequestFormat()) {
      case 'json':
        $prettyprint_lang = 'js';
        $content = json_encode(json_decode($response->getContent()), JSON_PRETTY_PRINT);

      case 'xml':
        $prettyprint_lang = 'xml';
        $content = $response->getContent();


      '<html><body>' .
      '<pre class="prettyprint lang-' . $prettyprint_lang . '">' .
      htmlspecialchars($content) .
      '</pre>' .
      '<script src="https://cdnjs.cloudflare.com/ajax/libs/prettify/r298/run_prettify.min.js"></script>' .

    // Set the request type to HTML
    $response->headers->set('Content-Type', 'text/html; charset=UTF-8');

    // Overwrite the original response

Then you just need to register the listener inside your bundle to the kernel.response event, which I suggest you do only in the dev environment config.

  # ...
    class: Acme\APIBundle\Event\Listener\ConvertToHtmlResponse
      - { name: kernel.event_listener, event: kernel.response }


You can just open a seperate browser and browse to …/app_dev.php/_profiler/ there you will find all your requests done to app_dev.php including oute matching, DB queries involved, etc.


With the FOSRestBundle, I use a special template to display the data in an html page, therefore with the debug toolbar.

In my controller with annotations (you also use corresponding methods):

@View(template="AppBundle:Api:data.html.twig", templateVar="data")

And in the template, choosing whatever format you fancy:

    <pre>{{ data | serialize('json') }}</pre>

It is obviously a quick&dirty solution, but does the job. It also limits the ability to display actual html pages on those routes.