HTTP allows for multiple representations of a resource. The
Accept header allows the client to choose the representation of the resource.
GET /foo/bar HTTP/1.1 Accept: application/pdf GET /foo/bar HTTP/1.1 Accept: text/html GET /foo/bar HTTP/1.1 Accept: image/svg+xml
If the response is 200 OK, the entity is expected to be the resource as that content-type.
But in the spec (RFC 2616), there are a lot of references to entities that aren't resources: 201 Created, 202 Accepted, 409 Conflict, 5xx, etc.
For example, for a 403 Forbidden response:
The server understood the request, but is refusing to fulfill it...If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity.
But what is the type of the entity? An HTML page? JSON?
As I read the standard, the
Accept header applies only to the resource entity. It would be odd to generate a PDF of why the server was in error, just because the request was for an
There is a way to have multiple representations of resources. Is there a standard mechanism to have multiple representations of errors? (In my case, there are clients that either use primarily JSON, or primarily XML.)
I realize I can always make a
X-Paul-Conflict-Accept and the
X-Paul-Create-Accept and the
X-Paul-Forbidden-Accept headers; I was curious if there was a usual way of handling this.