Selected Sources

• This lecture was created by first reviewing the available literature on REST design methodologies
• Not much was available, and it is relatively simple and, I think, naive
• How to Create a REST Protocol by Joe Gregorio (December 01, 2004)
• Also the set of related articles (also by Gregorio)
  • Show Me the Code
  • Implementing REST Web Services: Best Practices and Guidelines
  • Putting REST on Rails
  • The REST of the Web
• Other papers of possible relevance
  • Web-Calculus: Powerful Web Services Through Composition (2003-10-01)
  • Scalable, document-centric addressing of semantic stores using the XPointer Framework and the REST architectural style by Bryan Thompson, et.al, Proc. Extreme Markup Languages, 2004
  • RESTful Web Services by Stefan Marr
  • WebDAV vs HTTP method semantics by Roy T. Fielding (Aug 2001)

REST Notional Architecture

• The REST service architecture uses a modified version of the MVC design pattern, both on the server side and on the client side MVC means Model-View-Controller
  	Figure 1. Notional REST Architecture

• On the server, MVC is mapped to the following components
  • The View is the external interface (the API) and representations accessed by any client of that server
  • The Model is the internal representation of the resources provided by the server. Note that the internal representation and the external representation are separate and the mapping between them may not be one-to-one
  • The Controller is the code that implements the semantics of the external API and translates between the external representation and the internal representation
• On the client, MVC is mapped to the following components
  • The client has no "Model" as such. Its model is the view provided by the server
  • The View is some user-viewable interface over the resources provided by the server
  • The Controller is the code that implements the view using the resources provided in the server's external representation

Step 1: Designing the Server's External Interface

REST Elements

• The interface consists of the following elements

Resource structure graph URI tree Representations for each node type in the graph/tree Defined operations on each resource type

Figure 2. Resource/URI Graph Example

Defining the Resource Graph

• Resources are objects with relational links to other resources
• The links form a graph over the set of resources (Figure 2)
• Example:

  groupset(Addressbook,Groupset)
  group(Groupset,Group)
  groupmember(Group,Member)
  memberset(Addressbook,Memberset)
  member(Memberset,Member)
  

Defining the URI Hierarchy

• Resources have a primary hierarchy organization imposed by a corresponding URI hierarchy
• The URI hierarchy is formed as a spanning tree over the resource graph by specifying, for example, the primary relations to follow
  • Non-tree edges are encoded as elements in resource representations
  • Note: this constraint could be lifted; there is actually no obvious reason to limit URI's to a tree; any legal path through the graph could be specified as a URI
• Figure 2 shows the spanning tree in solid lines.

URI Tree Grammar Example

Node Representations

• Each resource has one or more "representations"
• Each representation is some kind of document that is returned as the result of referencing the URI accessing that resource
• This methodology assumes that URIs make no explicit reference to files at the end of the URI
• Equivalently, every URI explicitly ends with "index.html"
  • But this does not mean that a physical index.html actually exists; the controller decides this.
• When a resource has multiple representations, there must be some means to choose the desired representation using some combination of:
  • HTTP header lines: e.g. Charset
  • Intrinsic URI (URI with parameters): e.g. .../x?view=html
  • URI extension: e.g. .../x/html

Syntactic Specification Options

REST Semantics

• The REST interface has both syntactic and semantic components
• The semantics are implemented by the controller using the information in the model
• A variety of semantic specifications must be defined for a REST interface
  • CRUD Operation Semantics
  • A decision must be made about the semantics of the operations GET,PUT,POST,DELETE
  • Issues:
    • POST == create, PUT == update, or vice versa
    • Can PUT/POST create?
    • Can PUT/POST delete?
  • Security: Confidentiality, Authentication
  • Integrity: is the data provided by client valid?
  • Exception and Error Handling
  • ACID Transactions

Specifying REST Interfaces

• The existing WSDL interface notation is not ideally suited for specifying REST interfaces
  • WSDL Supports multiple operations as opposed to the standard GET,PUT,POST,DELETE of REST
  • WSDL has not way to support the URI hierarchy and the mapping to representation specifications
• Consider developing RESTDL as a mutatation of WSDL that incorporates some set of specification notions as described above.
• Try to keep somewhat consistent with WSDL

REST Client Design Elements and Issues

Recall that on the client, MVC is mapped to the following components (Figure 1)
• The client has no "Model" as such. Its model is the view provided by the server
• The View is some user-viewable interface over the resources provided by the server
• The Controller is the code that implements the view using the resources provided in the server's external representation
• The design methodology must support the definition of the view as well as the client-side controller.
• The client side may provide different views of the REST resource representatons
  1. Direct pass thru of the server's REST API (lo-rest)(restricted to GET/POST)
  2. (Object Oriented) Programmatic API wrapped over the direct REST interface.
• #1 is viewed using a web browser
• #2 is viewed using some view + controller (which might be a web browser using e.g. AJAX).

Client-Side Mapping of REST to Object Interface

• A relatively simple mapping suffices:
• Map each resource to an Object class
• Define the four CRUD methods: create, read, update, delete for each Object class

Server Side Controller

• Recall our architecture (Figure 1)
• Controller maps between the external and internal representations
• Controller can be designed using a plugin architecture
• Map (URI x Operation) => handler for that case
• Possible exception: static GET
  • Actually construct and store representations as index.html documents
  • Utilize e.g. Apache's ability to efficiently serve static content

Server Side Model

• The server model can be any suitable storage system.
• It might be desirable to build a standard controller that assumes a relational database as a backend.
  • Rely on ODBC/JDBC?

More to come...