application/xxx+json
Why did RFC-4267 not leave room for a JSON-family of representations? For XML, RFC 3023 formally defined XML-based media types using the "+xml" naming convention, so that clients (e.g. XMLHttpRequest) can recognize any XMLish media type as long as the media type follows this convention. But not so for JSON?
never understood that either. i recall some discussions about making sure JSON -stayed_ JSON and not e/de-voled into something else. but i don’t recall any talk about the MIME-type.
FWIW, i use application/vnd.my-object+json quite a bit internally.
[Reply]
Mike Amundsen
9 Oct 08 at 5:20 pm
It’s been discussed in the past, but JSON is still considered too new on the block to merit a +suffix.
+xml makes a certain amount of sense because there are a few interesting things you can do with a format if you know it’s XML, even if you don’t know its specifics; e.g., hand off to an XSLT processor. JSON doesn’t yet have either that shared set of useful generic tools, or enough formats that are genuinely at the level of an Internet media type (i.e., something you persist and interchange between systems that span more than a single application).
Besides, if every up-and-coming metaformat wanted a +suffix, we’d be up to our eyeballs in them :) Sometimes I wonder if there’s any real value in +xml, much less others.
[Reply]
subbu Reply:
October 11th, 2008 at 9:39 am
The only reason is that application specific media types with accompanying media type specifications, will let clients figure out what to expect or what to send.
For instance, when a client sees a Content-Type: application/vnd.amazon.book+json, it can refer to that media type specification (albeit an informal one) to interpret its syntax and semantics. The same goes for requests as well. When a client finds that a given URI can process application/vnd.amazon.book.comment+json, it can refer to that media type to learn how to construct the request body.
In that sense, by using these extension media types, we can live without something like a WADL.
[Reply]
Mark Nottingham
10 Oct 08 at 9:23 pm
yeah for media types, boo for WADL.
[Reply]
Mike Amundsen
11 Oct 08 at 9:42 am
I never liked the +xml style. Why not use mime type properties to specify the schema? The problem with +xml is that your browser isn’t gonna grok it most of the time.
I talked about it more here:
http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation/
[Reply]
subbu Reply:
October 26th, 2008 at 8:06 pm
I am not against +xml or +json like media types since they let the server or the client “describe” the type of the representation being transmitted, just the same way the namespace URI can describe the type of an XML document. The key difference between these two is the media type makes the representation self-describing.
I agree with Steve Vinoski’s comment that you can’t expect it to work across the internet. However, his comment applies to generic clients such as browsers, and not clients that you and I are creating for specific applications where we need to be able to understand how to process a message without looking at the contents of the body or by “guessing” by looking at the URI or something else.
Secondly, I don’t necessarily see using a MIME property such as “schema=…” very different from using “+xml”. Clients that understand application/xml do understand media types ending with “+xml”. The MIME type specification of, say, a “application/vnd.foo+xml” could very well describe a schema along with other useful information about that media type.
[Reply]
Bill Burke
23 Oct 08 at 2:27 pm