18908Re: [rest-discuss] API errors and media-types
- Jul 1 5:05 PMI hadn't thought about using custom media types for errors, but I have run across the Webmachine behavior you mentioned, and believe it to be a bug. Although sending a 415 when the client does not accept the "natural" media type served with another error (409 in your case) is unconditionally compliant with HTTP/1.1, this SHOULD is specifically called out in the spec as one that servers may find useful to relax--and this is a good example.I'd probably choose to serve a 409 with the error media type most likely to make sense to a human reader in this case, as I'm not sure I would expect a client to be able to recover from the error automatically if it didn't advertise support for one specifically in its Accept header.Jon
........Jon MooreComcast Cable
Given that you have a specific media-type(s) for giving extended API errors e.g. application/vnd.andrei.error-v1+json, application/vnd.andrei.error-v2+json
which of the following do you find natural?
#1 Be specific about which error media-type(s) you can accept
Accept: application/vnd.andrei.some-media-type-v1+json, application/vnd.andrei.error-v1+json
#2 If the client lacks specification of an error media-type, assume that it can process the lowest/highest version
#3 If the client lacks specification of an error media-type, do not return any media-type nor payload - just the HTTP status code
The thing is that for #1 and #3 to take place, basho's webmachine for instance would have to do content-negotiation again, but only for the media-types defined as error media-types and without throwing a 415 MEDIA TYPE NOT SUPPORTED.
Thank you for your time
NB. I've posted the above and some more comments also at https://groups.google.com/forum/?hl=en&fromgroups#!topic/api-craft/7c4unolo8Rw and I'd want to pick your brain as well
- << Previous post in topic