Re: [ietf-types] Review of application/vnd.error+xml and application/vnd.error+json

[Ben Longden <[e-mail]>]

Hi Jan,

On 29 Apr 2012, at 01:29, Jan Algermissen wrote:

> E.g. instead of having some "Order does not exist error" design an 'order' resource semantic and use 404. There is no error condition that you cannot express that way, in terms of the uniform interface that HTTP provides.

Yes and in that situation (Order does not exist), 404 would be the correct response. What if you POST an order for an item, however there is a validation error that prevents the request from being processed. I'd return a 422, perhaps with a text/plain response containing a simple error message. The problem is that without any extra semantics, I cannot for example link to a document that explains what the correct parameters are (accepted values etc), or identify which field contained the error message along side the human readable error.

>> Even your example below is doing that.
> 
> How so?
> 
>> If you have a web api's then you *must* communicate using media types over HTTP. In the case of a web client, adopting this proposed standard means this is understood and disparate clients can understand the same message.
> 
> The uniformity of HTTPs applies to the visibility components have in the *absence* of understanding the entity media types. A cache or monitoring intermediary can take action upon a 404, they cannot do that upon e.g. your proposed id="" attribute.

Agreed. I'm not advocating this as a replacement to the status code header. The id attribute is for carrying the specific reference to an error log entry on the server. This could be a URL (and perhaps should be a link with a defined rel in the spec, since out of bands information would be required to do anything with it!), but could be a database id with more specific information.

>> 
>> If I just use text/plain then I run into problems when I want to represent anything other than just the message (i.e, the id), and then have a requirement for a media type that can represent it.
> 
> Hmm, but it is exactly the error-id that I am arguing against :-)

Does that still hold true now that I have explained how I intended the id to be used? Perhaps changing this to a link with rel='service' (http://www.iana.org/assignments/link-relations/link-relations.xml) would make more sense.

Ben.