I’ve been playing around a little bit with the idea of creating a RESTFul MOM/ESB where the client requests a specific format and the server transforms the content if it can. For an ESB, this usecase would normally turn up for various XML-based messages and documents. The client would request an XML document of a certain schema and the ESB would return that format, performing a transformation if applicable.
For a RESTFul ESB, I’d want to use HTTP content negotiation. The problem is, AFAIK, there is no standard MIME type, other than “application/xml”, that allows you to specify an XML format with schema information. Being a REST noob, I emailed my friend Steve, a REST enthusiast, and asked him if it would be ok to embed schema information into the media type. My first thought was the media type would be:
application/myschema+xml
Steve’s response was you can’t just make up a MIME type on your own and expect it to work well on the Internet without registering it. At first I thought, what’s the big freakin deal? But then I realized, what if you want to point your browser to a message in a remote RESTFul queue and just view its content? If you use “application/myschema+xml” your browser ain’t gonna understand it.
So, I decided to do a search on “decentralized mime types” and came across a few blogs from Stefan Tilkov, Dan Diephouse, and James Strachan. Here’s a summary (sorry if I left out anything)
Use AtomPub
One idea was to use AtomPub . I don’t like this idea at all. One, I just want to send a bloody XML document! KISS baby KISS! Second, if I’m going to use an envelope format, why not just use SOAP and WS-*? (no thanks). This, IMO, sort of defeats one of the general principles of REST.
Define a new decentralized MIME type
The idea would be to define a decentralized MIME type like this:
application/data-format;uri=http://mediatypes.example.com/foo/bar
The uri would point to something like an RDDL document that defined the real format. Beyond KISS, what I don’t like about this approach is that again, I have no way of pointing my browser (or some other generic client) at the resource and just viewing it.
Use MIME properties
I saved the best for last. The final idea was to embed format information within MIME properties:
application/xml; schema="http:/..." application/octet-stream; data-format=java
Use a registered MIME type, but append extra format information as a MIME property. I did a test on this with Firefox and Safari and it doesn’t screw up the viewing. So for me, MIME properties it is! I would be interested in links to other thoughts on this.
Mar 07, 2008 @ 08:30:20
Hi Bill. Yes, the MIME extension does work. If I recall, we played around with this approach in early W3Objects work, but that wasn’t intentionally REST based back then.
Mar 15, 2008 @ 19:14:17
MIME properties can offer a lot of flexibility, such as specifying the version. I don’t know that Sun actually does anything with it, but the Java plugin specifies both the type along with the versions it supports. With that said, you could even extend this idea to support different versions of the same type. This opens up the possibility to potentially support older clients while also offering new features to updates clients, all without having to alter the services URI structure.
Ryan-
Oct 23, 2008 @ 22:17:46
I’m not a fan of the MIME properties approach. Also, while it would be *nice* if browsers would auto-magically render custom MIME types, that’s not a valid primary criteria for defining new MIME types, IMHO.
As for defining new types, registering them, etc. – i use the aplication/vnd.* without too much concern. true, some folks will not know what this MIME type is but that’s not very important for most applications. In fact, i usually use these custom MIME types for versioning and allow “application/xml” or “text/xml” to be mapped to the most recent version anyway.
Oct 24, 2008 @ 12:22:11
Mike, thanks for your opinion, but you didn’t express *why* you didn’t like the properties approach. I just don’t see any logical difference between the vnd.* approach and the properties approach except the properties approach is more usable in other environments.
Dec 21, 2009 @ 22:38:42
Hi Bill, thanks for the good summary and the links. You mention server-side transformation as your motivating problem. I looked at something rather similar for my DPhil thesis. My work was based on the idea of using a graph to represent the available transformations, which allows you to use a simple shortest path algorithm to find a transformation between two arbitrary datatypes.
These posts re-sparked my interest, so I’ve written a follow-up here, if you’re interested.