Subject: Advanced Internet Technology

Topic: RIA and Mashup

Difficulty: High

REST architectural Model

1. Resource-based

• REST is resource based API because RESTful API is as below points
• Things vs Actions
• Nouns vs Verbs
• Identified by URIs
• Multiple URIs may refers to same resource as like CRUD operation on student resource using HTTP verbs.
• Separate from their representations-resource may represent as per as request content type either JSON or XML etc.

1. Representation

• How resources get manipulated
• Part of the resource state-transferred between client and server
• Typically JSON or XML

For Example-

Resource– Author (Dinesh)

Service– Contact information about dinesh (GET)

Representation-name,mobile, address as JSON or XML format

Architectural Constraints

• Six guiding constraints define a RESTful system. These constraints restrict the ways that the server may process and respond to client requests so that, by operating within these constraints, the service gains desirable non-functional properties, such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability.

• If a service violates any of the required constraints, it cannot be considered RESTful.

• The formal REST constraints are as follows:

  1. Client–server – By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.

2. Stateless – Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

3. Cacheable – Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.

4. Uniform interface – By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

5. Layered system – The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.

6. Code on demand (optional) – REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented.