Rich Representations

Resource representations: they capture a snapshot of the state or intended state of a resource.

When you think of REST it’s natural to think of resource representations as a stream of binary data sent over a network ready to be consumed by a client. However, except in the degenerate case of serving static data and downloading it to your hard disk, that representation must always be “serialized” by the server and “parsed” by the client. That’s obvious you say! Well it is if your client and server are network separated but in a Resource Oriented Computing (ROC) platform most requests are local, running on the same host.

Marshalling resource representations through a binary stream has two negative implications. The most obvious is the overhead of serialization and parsing processes. The second relates to the development and on going maintenance costs of the system. It you are going to have a serialized form that may well incur additional work, agreeing the wire-format and developing the serializing and parsing.

In ROC a resource representation can be any old object model with one proviso; it must be immutable. Without immutability multiple clients could communicate through side-effects either between themselves or with the service.

The first implication of this freedom is that representations gain an additional second dimension of typing. The first, original, dimension is the logical type, i.e. what is it? In an Internet systems this is the MIME type. The second dimension is the physical object model of the representation. In networked resource systems this second dimension was fixed, always being a binary data stream.

Here are some examples:

  • An open office text document with a MIME type application/vnd.oasis.opendocument.text embodied as a binary data stream.

  • The RSS feed to the 1060 Forum [] embodied as a DOM object model

  • The Powered by NetKernel [] logo embodied in a java.util.Image object model

  • The complete works of William Shakespeare as an audio-book embodied as a binary data stream in MP3 format.

  • Employee “Tony Butterfield” embodied as a application specific POJO representation with the 1060 Research HR application.

The second, more interesting, implication is that these rich representations lead the way for unification of many processes which currently have separate names and are considered separately. Processes such as compilation, parsing, serialization, encoding, indexing etc. can all be considered as changing the representation of resource from one physical form to another; trans-representation, or the contraction transreption. Within ROC transreption is performed by “transreptor” endpoints resolved within address spaces. Transreptors may be invoked implicitly to adapt physical representations between service and client or explicitly requested. Implicit transreption leads to loose coupling by allowing services to be built without functionality to understanding anything other that the object model they work with. It allows two services to communicate even if they work with different object models as long as a transreptor can be resolved to bridge the gap.