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 application/pdf
.
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.