Subject: [apps-discuss] draft-nottingham-http-problem-04 and content types

From: Daniel Spangler <[email-masked]>
Date: Sun, 3 Nov 2013 22:40:06 -0500

Hi,

I recently stumbled upon this and am very excited about it, because I feel
like I've built something like this several times in an ad hoc way.  I've
been thinking about implementing a version of it for fun, and was curious
to get your opinion on how you think content type negotiation should occur.

The spec introduces two new content types application/api-problem+xml and
application/api-problem+json that an error response would contain.

How do you envision knowing which one of these to return?  Would it be
something statically defined, derived from the accept type, or specifically
declared in the accept type?  Is there any concern with returning a content
type that is not explicitly defined in the accept header?

Sincerely,

Daniel Spangler

---

From: Erik Wilde <[email-masked]>
Date: Sun, 03 Nov 2013 19:54:26 -0800

hello daniel.

On 2013-11-03, 19:40 , Daniel Spangler wrote:
> The spec introduces two new content types application/api-problem+xml
> and application/api-problem+json that an error response would contain.
> something statically defined, derived from the accept type, or
> specifically declared in the accept type?  Is there any concern with
> returning a content type that is not explicitly defined in the accept
> header?

i don't think there's anything special about the HTTP problem types 
here. if a server supports both variants, and a client does not specify 
a preferred variant, or does not distinguish which one it prefers when 
asking for both, then it's up to the server to respond which whatever it 
thinks is the better default choice:

- maybe JSON because on average, people seem to like JSON better these days.

- maybe XML, because you can associate it with an XSLT and thus render a 
nice human-readable response in a browser.

it really is up to the server to decide what to do; it could even serve 
XML/XSLT to browser clients, and JSON to non-browser clients. as 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-5.3.2 
puts it:

"A request without any Accept header field implies that the user agent 
will accept any media type in response."

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |