2

I have two problems:

(1.)I want to know that what is the best way to show Error Messages in REST API.

Should I throw Exceptions or should I use VIEW to show error messages with status code etc. details.

I am using FOSRestBundle to handle rest related tasks.

I am sending API Usage data in each response(without asked by API consumer).

(2.) If I use exception how to add my custom data to in headers with error message.

Ashish Awasthi
  • 1,484
  • 1
  • 19
  • 34

3 Answers3

1

With RESTful APIs, you always use HTTP codes to provide meaningful messages to the client.

To do this, you use a Response object to send a variety of HTTP codes. Symfony provides a few Exception handling scenarios which will result in 403, 404, or 500 errors, but not as extensive as this list. All exceptions will do is throw the same HTTP codes that you could achieve manually, albeit with more meaningful internal debugging errors in the development environment but with less control.

To send a meaningful HTTP error code (such as an object being successfully created):

use Symfony\Component\HttpFoundation\Response;

$response = new Response(
    'A custom message or an XML/JSON/anything object',
    Response::HTTP_CREATED,
    array('content-type' => 'text/html')
    // Can also be application/json or application/xml .. list goes on
);

but since you're using the FOSRestBundle already, you should be reading the documentation about the view layer and how to use it instead. The view layer will already handle these HTTP codes for you and provide responses in multiple formats just like a RESTful interface should.

sjagr
  • 15,983
  • 5
  • 40
  • 67
  • Here Question is not sending response its how to handle errors and whats the best way to show them either throw exception or use view? By your answer I'll consider it as giving suggestion to use view to show the errors, with custom data – Ashish Awasthi Oct 15 '14 at 18:12
  • @AshishAwasthi Use views. Why do you think the construct for `view` is something like `view($data, 200)`? It's so you can modify that HTTP code response to whatever you want it to be to show meaningful responses to the client. – sjagr Oct 15 '14 at 19:00
  • I agree on the point that we can use views, but the question was which one is better approach showing custom messages using views or throwing exceptions. Exceptions are also internally converted into response by FOSRestBundle so they will also give you the same json or xml response. So Now same thing can be achieved by VIEWS or Exceptions so I want to choose one and Better one. When I use to throw Exceptions they give advantages in Unit Testing as I can test them by @expectedException but that is not he case with Views. – Ashish Awasthi Oct 16 '14 at 05:40
  • @AshishAwasthi Unfortunately asking for a "best approach" on SO will not yield you with a definitive answer, sorry – sjagr Oct 16 '14 at 13:02
0

As you can see here you can add a listener for kernel exceptions.

Inside that listener you can define the headers and status code of the response, like that:

    $response = new Response();
    $response->setContent($message);
    $response->setStatusCode("YOUR_STATUS_CODE");
    $response->headers->replace("YOUR_CUSTOM_HEADERS");

    // Send the modified response object to the event
    $event->setResponse($response);

Personally I prefer throwing exceptions, but try to make them as specific as it gets. This way the consumer of the API is able to handle different types of exceptions.

Nonetheless if a generic exception is thrown (means that something has gone horribly wrong), you can still return a properly formatted response and the consumer will be able to also handle failure

montexristos
  • 290
  • 2
  • 5
  • Thats right we can create Listeners and can add data to response using it, and me too like to throw exceptions but, Which one is better and why is the question :) – Ashish Awasthi Oct 15 '14 at 17:00
  • 1
    What I meant, and probably was not too clear in my response, is that by using exceptions you handle errors that are anticipated (like missing parameters in the request) and errors that are not (database connection error) in a unified way. Working like that you ensure that consumers can handle with ease any failure of your API. I don't see any other difference since you will always return the same response object with your custom error messages and status codes – montexristos Oct 16 '14 at 07:28
0

I had the same question and issue. Searching for the answer led me to this question. I eventually managed to get it working and I posted an answer to a similar question (the code in the question is very helpful too) here: FOSRestBundle configuration of exceptions messages in prod environment

This documentation was also helpful, although not very clear I thought: https://symfony.com/doc/current/bundles/FOSRestBundle/4-exception-controller-support.html

Community
  • 1
  • 1
timhc22
  • 7,213
  • 8
  • 48
  • 66