As REST (and REST-over-HTTP) adoption grows for more than just running your favourite Web server, we are seeing more and more people bring their real-world experiences to a wider community. In this case Benjamin Carlyle asks whether MIME types are holding back REST?
A significant weakness of HTTP in my view is its dependence on the MIME standard for media type identification and on the related iana registry. This registry is a limited bottleneck that does not have the capacity to deal with the media type definition requirements of individual enterprises or domains. Machine-centric environments rely in a higher level of semantics than the human-centric environment of the Web. In order for machines to effectively exploit information, every unique schema of information needs to be standardised in a media type and for those media types to be individually identified. The number of media types grows as machines become more dominant in a distributed computing environment and as the number of distinct environments increases.
The problem as Benjamin points out, is that getting universal adoption of various MIME types is extremely difficult and doesn't scale. Just getting agreement on why a particular type may be required is hard enough, without then trying to agree on what the type is and how it should work.
The ability to experimentally define and evolve these standards outside the Web is essential to a healthy adoption of the REST style and related styles beyond the Web.
Benjamin then goes on to suggest some alternative approaches. The first would be to use URNs, particularly since they already provide a decentralised registry. But as he points out, there are problems here too. "The first is simply that HTTP does not permit their use in the appropriate headers. The second is that URNs cannot be further interpreted when they are read. The third is that URNs cannot be parameterised as MIME types are." MIME types offer a very powerful way in which to define conformance or compliance across different types that would be hard to represent using URNs alone. He goes on to propose some changes to HTTP that would facilitate using URNs as a replacement. For example:
The solution to these problems could be a revision of HTTP to include URI syntax support for media types, combined with a protocol whereby processors could determine whether one media type inherits from another. [...] One could either make use of HTTP headers in the GET response for the URI, or specify a new media type for media type description. The obvious approach with link headers would be to say Link: rel="inherits". However, this is a limited approach. An actual media type description media type could take the form of a short XML document or simple microformat for human-readability, and is perhaps more general and future-proof.
Of course as he points out, backward compatibility is extremely important in the Web so any changes that were made would have to occur with careful consideration for this aspect. However, Benjamin does have another alternative to offer: a decentralized registry in MIME syntax.
An alternative to going all the way to URNs might be to make use of the DNS system alone as part of a media type identifier. For example, a "dns" sub-tree could be registered under MIME. The sub-tree would allow an example organization to safely maintain a set of identifiers beginning with application/dns.com.example without IANA coordination. Any organization with a presence in the DNS tree could do the same.
This addresses the backward compatibility issue in as much as it doesn't affect HTTP. It also seems to maintain the advantages of MIME syntax, such as inheritance. But there are still downsides:
Perhaps the strongest argument against this alternative is a loss of discovery of standards documentation. URLs can easily be dereferenced to locate a specification document. This hybrid of DNS and MIME would need additional help to make that so. It would be necessary to have a means of translating such a MIME identifier into a suitable URL, which quickly leads into the world of robots.txt and other URL construction.
There are a couple of other variants of these approaches that Benjamin presents, but as he concludes:
I'm torn on this one. I don't want to go to the IANA every time I publish a media type within my enterprise. I like URLs, but want a straightforward way to discover important inheritance relationships. I don't want to break backwards-compatibility with HTTP, and there is no better protocol available for the business of doing REST. What's a boy to do?
So is the current MIME approach as limiting as this article suggests? Are there other approaches that could be used? It seems that the problem with MIME isn't so much the MIME protocol as the way in which new types are controlled.