Reputation: 1079
I have a REST service that supports various media types (MIME types) such as application/xml
, application/json
, application/vnd.ms-excel
, text/plain
. This service is consumed by browsers requests as well as HTTP clients in application code.
However, when consuming this REST service, my client code needs to handle errors in a consistent manner. To do this, the error payload would have to be in consistent media type like JSON so it can be deserialized.
So my question is, am I breaking any RESTful best practices if I return an error payload which in inconsistent with the requested media type? If not, what format should I use? JSON?
Update
To clarify, when I say error payload, I am referring to the body of a response which has a status other than 200 and which needs to contain error details.
Upvotes: 1
Views: 1602
Reputation: 239470
First, an error doesn't have to include a payload. It's perfectly reasonable to just return a status code like 401 with an empty response body. However, if you need to return payload, then the response for an error should be same as the expected type for success. In other words, if the client requested JSON, return JSON both on success and error. Likewise, if XML was requested, the error response should be in XML.
Upvotes: 3