Media Types

One way to look at media type design is to create a document format|language that is capable of expressing all the required state transitions for your app domain. You should be able to use a single media type to share all the needed state transitions.

A simple way to do this would be to (in XML-style) declare a set of top-level elements that will contain each transition. For example, consider a very simple use case where a client and server need to share information about the status of one or more "orders." A single document format might allow for lists of orders and a single order display. Clients could change the status of orders by posting an updated single-order state:

<root>
  <!-- possible states -->
  <all-orders />
  <pending-orders />
  <inprocess-orders />
  <completed-orders />
  <cancelled-orders />
  <single-order status="" />
</roo>
          

There are lots of problems (missing|unclear details) in the above example, but it stands as as simplistic instance. Using this document model, clients and servers can look for and "understand" this handful of states and handle the contents of the document accordingly.

While the HTTP RFC discourages the use of non-registered media types, doing so is not required. In the parlance of RFC documentation there is no MUST associated with the use of registered media types. Anyone who claims otherwise is blowing smoke, plain and simple.

That being said, it is a "good thing" to register the media types you create with the IANA. Not only that, it is quite simple and easy to do so; especially if you choose to use the .VND or .PRS  registration trees. These require only proper attention to fill out registration documents and file them with the IANA.

However, if you plan to register your custom media type in the "IETF" (standards) tree, you'll need to go through a more rigorous technical review. It's not impossible or improbable that your type will pass the review successfully, it's just a bit more time-consuming.

Either way, registration is a "good thing" and everyone who uses custom types, no matter how trivial the type or how infrequently you use it, should do the simple work of adding your media type to the public registry. Who knows, maybe your media type will be noticed and used by others. And you might have the opportunity to promote your custom type from the vendor or personal tree up to the standards tree.

And that would be cool, right?