High in the Cloud

REST paper notes

Posted by: blukee on: June 28, 2010

(Fielding and Taylor 2002)

Why am I reading this?

Get to know REST. Can it be applied to my dissertation as the architecture?

What are the authors trying to do in writing this? (Abstract, Introduction, Conclusion)

The authors focus on the rationale behind the modern Web’s architectural design and the software engineering principles upon which it is based.

.

What is the motivation for this work (both the development and the technical problem)?

“what was needed was a way for people to store and structure their own information, whether permanent or ephemeral in nature, such that it could be usable by themselves and others, and to be able to reference and structure the information stored by others so that it would not be necessary for everyone to keep and maintain local copies.”

The challenge was to build a system what would provide a universally consistent interface to this structured information, available on as many platforms as possible and incrementally deployable as new people and organizations joined the project.

What is the proposed solution (hypothesis, idea, design)?

REST focus upon the generic connector interface of resources and representations.

Representational State Transfer: it’s a coordinated set of architectural constraints that attempts to minimize latency and network communication while at the same time maximizing the independency and scalability of component implementations.

Web pages -> Virtual State machines

Selecting a link or submitting a form -> State Transition -> transfer a representation of that state to the user.

Requirement of Modern WWW: the challenge was to build a system that would provide universally consistent interface to this structured information, available on as many platforms as possible and incrementally deployable as new people and organization joined the project

History:

Client-Server: separating the UI concerns from the data storage concerns. Improve the portability of UI across multiple platforms and improve scalability by simplifying these components.

Client-Stateless-Server: Each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is kept on the client. This induces the:

  • Visibility- monitoring system does not have to look beyond a single request data message to determine the full nature of the request.
  • Reliability- eases the task of recovering from partial failures.
  • Scalability- server doesn’t need manage resource used across requests.

Stateless constraint trade-off:

  • It may decrease network performance by increasing the repetitive data-per-interaction overhead sent in a series of request.
  • Placing the application state on the client-side reduces the server’s control over consistent application behavior.

Client-cache-stateless-server: enable cache of client or server to improve network efficiency.

REST emphasis on a uniform interface between components

  • Overall system architecture is simplified
  • Visibility of interactions is improved
  • Implementations are decoupled from the service they provided
  • Information is transformed in a standardized form.

REST interface is designed to be efficient for large grain hypermedia data transfer, optimizing for the common case of the web.

Layered system style: each component cannot see beyond immediate layer. Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionalities to a shared intermediary. Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors.

Disadvantage of layered systems: add overhead and latency to the processing of data, reducing user perceived performance.

Code-on-demand (COD) style is optional: client downloads and executes code (applets or scripts)

In order t obtain a uniform interface across multiple architectures. There are 4 constraints to behaviors of components:

  1. Identification of resource
  2. Manipulation of resource through representations
  3. Self-descriptive message
  4. Hypermedia as the engine of application state

Resource – Mr(t) is a function of time mapping to a set of entities/values.

Value- resource representations or resource identifiers. So the reference of resource refers to a concept/ semantics of a resource rather than some representations.

REST components perform actions on a resource by using a representation to capture or intended state of that resource and transferring that representation between components.

A representation consists of: data, metadata of data.

A response message may include both representation metadata and resource metadata.

Control data defines the purpose of a message. A give representation may indicate the following by control data.

  • The current state of the request resource.
  • The desired state for the requested resource
  • The value of some other resource. Such as a representation of the input data within a client’s query form.
  • A representation of some error condition for a response.

In parameters of a request:

-          Control data

-          Resource identifier

-          An optional representation

Out parameters of a response:

-          Control data

-          Optional resource metadata

-          Optional representation

Reference:

Fielding, R. and R. Taylor (2002). “Principled design of the modern Web architecture.” ACM Transactions on Internet Technology (TOIT) 2(2): 115-150.

Advertisement
Tags:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.