REST requires standard content types to be used in order to achieve network effects. You and I cannot understand each other if we don't understand each other's content. Even if we agree on the meaning of GET, PUT, POST, and DELETE we will still have to write new software when we want our software to talk to each other. So how do I go about selecting a content type that is suitable for use?    (5XA)

Step 1: Do your RESTful design    (5Y6)

RESTfulDesign consists of drawing up the set of URLs that your server will provide, drawing links between them that clients will use to navigate around, and defining the meaning of the state transfer operations you are doing on your resources. Out of this process will come a data schema for each resource.    (5XB)

Step 2: Look for schema commonality    (5Y7)

Once you have a schema for each resource, start looking for overlap. The goal is to have as few content types at the end of the process as possible. Resources with overlapping schemas can share a common representation. Each one will use a subset of the final representation.    (5XC)

Take, for example, a train object. It might have a location, a next platform, a terminus platform, and other information associated with it. Start to build up a picture from the perspective of all of your resources as to what information a train object may have.    (5XD)

Now, wherever you have a resource that has some subset of the data you provide it based on the common train schema. Even things that don't obviously look like trains or lists of trains might be able to be represented as an empty or non-empty list of trains.    (5XE)

Step 3: Look for standard content types    (5Y8)

  1. If your schema is effectively GET-only human-oriented content, look to the types on the web today. Use xhtml strict for formatted text, possibly with microformats included. Use svg, png, etc for images.    (5YF)
  2. If your schema is as simple as a single integer, or other type consistent with a built-in xsd type, use text/plain    (5XG)
  3. If your schema involves time or scheduling, see if you can make application/calendar+xml or application/atom+xml work for you    (5XH)
  4. Docbook, ODF, and UBL may also be good options    (60V)

If none of these fit,    (5XI)

  1. Look through the list of registered mime types for a match    (5XJ)
  2. Try minimially-enhancing an existing format to meet your needs, eg by adding special elements or a <tags> element    (5XK)
  3. Look to the microformats world for inspiration    (5XL)
  4. Develop your own content type.    (5XM)

text/plain    (5Y9)

Any of the xsd-data types can be encoded this way. They include date and time types as well. The xsd types are not "types" in the object-oritented sense. Instead, they are encodings that often overlap with each other. By using xsd types you are not deciding how your data will be consumed. Just because you think of something as an integer, doesn't mean the consumer of your data cannot think of it as a double. They encoding is neutral to these kinds of perspective shifts, as all REST design should be.    (5XN)

application/calendar+xml    (5YA)

This is xCal-Basic, and hasn't made it past IETF standardisation at this stage. It is the XML version of the ubiquitous calandering form, iCalendar. The microformats word have their own format for iCalendar, and are pushing for it to become the basis of their own time and date functionality.    (5XO)

This format is great for recording information about events. Take what you would have encoded into your text/plain body, and put it in the <description> element of the vevent. Use the other fields as intended. You may also be able to use the other element options within xCal, such as vjournal.    (5YD)

application/atom+xml    (60W)

This is atom, the increasingly popular syndication format. If you are syndicating data, this might just be the format for you. Use the <content> element for whatever you would have placed in the text/plain body. Use other fields as intended.    (60X)

This is a more standard, but differently-expressive alternative to xCal's vjournal option.    (60Y)

application/rdf+xml    (64B)

It seems RDF-based formats could also fit well into the picture. They have a nice versioning feature, as each term used can evolve independent of the others, unlike the stricter XML schemas. -- MaxVoelkel    (64C)

Microformats    (5YB)

At the time of writing, the microformats world is way ahead of XML in term of standardising on a simple common set of exchangable types. They have developed a promising approach to standard development that involves:    (5XP)

Whatever is standard in the microformats world should be easily transferrable back into the XML world, and synergies should develop between the two. This goes for actual formats, and for the methodology.    (5XW)

Rolling your own    (5YC)

It isn't harmful to create your own formats, especially for internal use. It can make engineering simpler if there is no need to study existing formats as part of the process to come to an optimum solution. What you lose in network effects can be gained back in engineering performance.    (5XX)

Beware that when you do create your own format you are walling yourself off from the rest of the world. Your software won't work with other software, because it doesn't share a common schema and encoding. That goes for "plain" rdf and "plain" xml documents, too. Agreeing on the encoding is not enough. Applications must agree on some subset of the schema of a document to do useful things with it.    (5XY)

The long-term objective should always be that your important content types are standard, either because they started out that way or because you spent years beating out the standard with your competitors and with participants from other industries. The more standard your content types, the greater the network effects between your organisation and others. Thus, the greater the value of the content type.    (5XZ)