Identifying the Resource and Representation REST promotes the separation of the resource from the representation. For illustration purposes, let’s work through the historical stock-ticker example. The URL used to retrieve the historical ticker information is /services/historical/AMZN/2006. The default format generated by the Web service is CSV, but the default could just as easily have been XML or JavaScript Object Notation (JSON). If a client can only accept JSON, then the conversion from CSV to JSON requires an extra step and extra resources.

To optimize this application, you can let the server decide which content to generate based on the needs of the client. If the client wants JSON, then the server will generate JSON. The data that is generated as JSON, XML, and CSV is all the same. Thus, it can be said that the data is the resource, and JSON, XML, and CSV are the representation. Separating the resource from the representation means that a single URL will have separate representations. The representation that is sent depends on the value of the HTTP Accept-* header, but doesn’t need to be the only one. Let’s focus on the Accept HTTP header and consider the following HTTP conversation that returns some content.

   Request
   GET /services/historical/AMZN/2006 HTTP/1.1
   Host: 192.168.1.242:8100
   User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS  X
   Mach-O; en-US; rv:1.7.8) Gecko/20050511
   Accept:  text/xml,application/xml,application/xhtml+xml,text/html;
   q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   Accept-Language: en-us,en;q=0.5
   Accept-Encoding: gzip,deflate
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   Keep-Alive: 300
   Connection: keep-alive
   Response
   HTTP/1.1 200 OK
   Date: Mon, 21 Aug 2006 14:51:40 GMT
   Server: Apache/2.0.53 (Ubuntu)
   Last-Modified: Thurs, 11 May 2006 17:43:45 GMT
   ETag: "41419c-45-438fd340"
   Accept-Ranges: bytes
   Content-Length: 69
   Keep-Alive: timeout=15, max=100
   Connection: Keep-Alive
   Content-Type: text/html; charset=UTF-8

The request is an HTTP GET, which means the HTTP server needs to retrieve the data associated with the resource. The operation becomes specific when the request provides the HTTP headers Accept, Accept-Language, Accept-Encoding, and Accept-Charset. These HTTP headers are accepted by the HTTP server and serve as an indication of what content to send. Focusing on the HTTP header Accept, the values are a series of MIME-encoded identifiers that the client will accept.

The order and type of the identifier are important, because they specify the priority of the content that the client wants to receive from the server. The logic is to send the content available with the priority defined by the client that, for example, forces the server to send HTML content before plain-text content. The priority of content is the priority of the MIME types as defined in the HTTP specification. The following list is generated when you reorder the example request:

1. application/xhtml+xml 2. text/xml 3. application/xml 4. image/png 5. text/html;q=0.9 6. text/plain;q=0.8 7. */*;q=0.5

The ordering of the identifiers depends on the identifier specialization and its q value. A MIME type identifier that has no q value indicates a default value of 1.0. When a q value exists, you must lower the priority of the MIME type identifier to the value specified by the q value. Identifier specialization is when one identifier is a higher priority because the specified content is more specific than the other identifier. In the list of priorities, the identifier text/xml is more specific than */* because */* means everything. Additionally, text/xml is more specific than text/*, and hence text/xml is a higher priority.

Note that the first MIME identifier from the HTTP conversation is text/xml, and the second is application/xml. Yet, in the priority order, the first MIME identifier is application/xhtml+xml. I made this assumption after having read the HTTP and MIME specifications, but I feel it’s a bug that just happened to work.

Let’s dissect the example request to understand why this bug happened to work. The MIME type identifiers application/xml, text/xml, and application/xhtml-xml are considered specific, and each has a q value of 1. If the server follows the ordering of the MIME types, it means that the browser prefers receiving XML content to HTML or XHTML content. The application/xml and text/xml MIME types are XML content, albeit the XML content could be XHTML content. Reading the specification solves the problem with the phrase regarding the priority ordering of the MIME types, which generically says that a more specific MIME type is ordered before a less specific MIME type. This means application/xhtml-xml is ordered before application/xml and text/xml, because application/xhtml-xml is specifically formatted XML. The example HTTP conversation illustrated that the browser was explicit in what it wanted. There are browsers though that do not explicitly indicate what they want, as illustrated by the following HTTP conversation.

   Request
   GET /services/historical/AMZN/2006
   Accept: */*
   Accept-Language: en-ca
   Accept-Encoding: gzip, deflate
   User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;  Windows NT 5.1; SV1;
   .NET CLR 2.0.50215; .NET CLR 1.1.4322)

Connection: Keep-Alive Some browsers send the Accept type identifier */*, which essentially means, “Send me whatever you’ve got; I will accept it.” Such a request is extremely unhelpful and makes it difficult to implement the separation of the resource from the representation. The solution to this problem is to define a default representation for the identifier */*. It’s not an ideal solution, but a solution begot out of the necessity to send something. Most likely, those clients that send */* are HTML-based Web browsers.