Is Proliferation Of Custom Media Types RESTFul?

Subbu Allamaraju, revisits one of the recurring debates in the REST community; the standard media types vs. custom media types and tries to determine the best practices when using them. He starts with the stating dichotomous views on the use of media types.

• Opinion 1: Web services must use standard media types to be RESTful.
• Opinion 2: Custom media types are necessary to keep interactions visible, and to serve as contracts.

The first opinion which, if adhered to strictly, per Roy Fieldings thesis, “the use of media types such as application/vnd.example.myway+xml is not RESTful”. Subbu believes that understanding the impact of such media type usage in the real world is more important than following the thesis to the letter. There are however comments that suggest that this interpretation of the thesis might be up for debate as well.

To the contrary, the second opinion, he says, leads to visibility of the messages at the protocol level via the use of custom media types.

[…] For instance, how can anyone know if a representation that uses application/xml media type describes a purchase order, or a photo album? If the web service uses media types likeapplication/vnd.example.po and application/vnd.example.album, then any one can interpret the semantics of the representation without parsing the body of the representation. Per this line of thinking, a media type is an identifier for message semantics, and message recipients use media types to trigger processing code.

“So what is the right thing to do?”  He asks, as he puts forth his idea, in a effort to democratically determine the best practices

• If the sender is formatting representations using standard extensible formats such as XML or JSON, use standard media types such as application/xml and application/json.
• Mint new media types when you invent new formats.
• If you are just looking for a way to communicate application level semantics for XML and JSON messages, use something else (e.g. XML namespaces and conventions).
• If the goal is versioning, use version identifiers in URIs.

Giving java-like examples, He asserts that though its possible to peek into the messages to see how a request can be processed, it compromises visibility or opacity as the case may be.

Media types such as application/xml and application/json are good enough for XML and JSON message processing in code. […] URI based approaches are guaranteed to work across the stack. Ignoring real-world interoperability for the sake of "architectual purity" or "RESTful contracts" may eventually back fire.

Via the post is the solution presented by Subbu found the right balance between architectural purity and interoperable real-world solutions? Be sure to visit the original post to weigh in your opinion.