REST – Resource Representation

At it’s heart REST, hypermedia and therefore HATEOS revolve around linking and managing resources.  Resources like nouns represent persons, places, things, concepts,  states, or qualities.  A resource is an available asset, representation of real-world entities, or a source of supply, support, or aid.  Though REST does not define what resource representations should look like, they should be easy to understand, parse and manipulate.

JavaScript Object Notation (JSON) is one popular format for data representation and transmission.  JSON is a simple and flexible system that compactly represents data as name-value pairs.  JSON is widely known for it’s readability, ease of use and ubiquity. JSON is most often found as the way JavaScript stores data in web applications.

Extensible Markup Language (XML) is another extremely common way to represent data.  XML is quite powerful because it allows for the creation of sophisticated structures in the data representation.  XML is crafted with a combination of open, closing and self-closing tags, tag attributes and of course the contents of the tags.   XML is readable, quite verbose (reducing it’s compactness), and like JSON is both easy to use and ubiquitous. The Extensible Hypertext Markup Language (XHTML) is the Hypertext Markup Language (HTML) that conforms to the conventions and guidelines of well-form XML in order to enjoy XML’s advantages.

Although the resource representation chosen is not significant to REST, there MUST be a resource representation to transfer state between clients, servers, and peers in an architecture built on REST.  Resource representations should be well thought out, consistent, easy to modify and most importantly tailored to the problem they are used to solve.