Outline What is ReST ? Constraints in ReST REST Architecture - - PowerPoint PPT Presentation

Outline

• What is ReST ?
• Constraints in ReST
• REST Architecture Components
• Features of ReST applications
• Example of requests in REST & SOAP
• Complex REST request
• REST Server response
• Real REST examples
• REST Design Guidelines
• Documentation
• Additional Reference

History

• ReST was introduced and defined in 2000 by Roy Fielding in

his doctoral dissertation. Fielding is one of the principal authors

• f the Hypertext Transfer Protocol (HTTP) specification versions

1.0 and 1.1.

• The REST architectural style was developed by W3C Technical

Architecture Group in parallel with HTTP/1.1, based on the existing design of HTTP/1.0. The World Wide Web represents the largest implementation of a system conforming to the REST architectural style.

What is ReST ?

• ReST stands for REpresentational State Transfer.
• ReST is an architecture style for distributed systems.
• ReST is a hybrid style derived from several network based

architecture styles combined with some additional constraints.

• ReST is not a protocol or standard.
• It uses simple HTTP to make calls between machines than

complex architectures like SOAP.

• It consist of Client and Servers where Client intitiates request

and Server responds to it using representation of resources.

Understanding Architectural Approach

• When processing an architecture style, we can :
• Building system from scratch, with necessary elements, for an

intended purpose.

• Building system by configuring system needs, incrementally

applying constraints and understand system behaviour which reflects the properties of modern Web.

• ReST was developed using the latter approach.

Constraints followed in REST design

• These constraints are applied on hybrid REST design sequentially:
• Client-Server.
• Stateless.
• Cacheable.
• Uniform Interface.
• Layered System.
• Code on Demand.
• The only optional constraint of REST architecture is code on demand.

Conforming to the REST constraints is generally referred to as being "RESTful". If a service violates any of the required constraints, it cannot strictly be considered RESTful Web Service.

Client-Server Architecture

• Seperated system of concerns.
• It improves portability of the User Interface across multiple platforms.
• It enhances scalability of Server component.
• Servers and clients may also be developed independently, as long as

the interface between them is not altered.

Stateless

• Client-Server interaction must be stateless in nature. Server contains no

client state. Any session state is held on the client.

• Each request must contain necessary information to be processed at server.
• It increases Reliability due to recovery from partial failures.
• It improves Scalability as server doesn't need to store the state of each

request.

• Visibility enhances as intermediaries don't analyse request's record.
• Server has minimal control over the application behaviour.

Cache

• Server responses (representations) may be cacheable or non-cacheable.
• Cacheable – Client cache can use response data.
• Non-Cacheable – Client cache has no privilege to use response data.
• Responses must therefore, implicitly or explicitly, define themselves as

cacheable, or not.

• Well-managed caching partially or completely eliminates some client–server

interactions improving scalability and performance.

• It may decrease reliability in case stale data within cache persists.

Uniform Interface

• Defines the standards followed between client and server.
• ReST's basic operation – HTTP Verbs (GET, PUT, POST, DELETE), URI

(Resource name), HTTP Response (Status, Body).

• The information being transferred has to follow standard rather than specific

application needs.

• Multiple architectural constraints are needed to obtain the uniform interface.

Principles of Uniform Interface

• Identification of resources : Individual resources are identified in
• requests. The resources are separate from the representations that

are returned to the client.

• Manipulation of resources through these representations : When

a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource

• n the server, provided it has permission to do so.
• Self-descriptive messages : Each message includes enough

information to describe how to process the message.

• Hypermedia as the engine of application state (HATEOAS) :

Clients make state transitions only through actions that are dynamically identified e.g. Hyperlinks.

Layered System

• Contraints applied on components as each component cannot see beyond

the immediate layer.

• Layered system constraints allow intermediaries like: proxies, gateways,

and firewall to be introduced at various points in the communication without changing the interfaces between components.

• Intermediary provide shared cache, security thus improving scalability.
• It may increase latency reducing user-perceived performance.

Code on Demand

• Server can temporarily extend client functionality by allowing them to

download and execute code in form of scripts/applets.

• Transfer logic to client.

Style Derivation Summary

• ReST consists of a set of architectural constraints where each

constraint has it's own feature.

• Their property is observed by their role in common architectural styles.

REST Architectural Elements

• ReST focus on components, constraints, nature and state of the

architecture's data elements.

• The format of the representation remains hidden through a generic interface.
• Use representation of resource for communication among elements.
• ELEMENTS :
• Resource can be any object, a collection of resources or refers to an

intended conceptual target or reference.

• Semantics distinguishes one resource from another.
• Resource Identifier is used to identify the particular resource involved in an

interaction between components, through URN or URL.

• Representation captures the current or intended state of a resource and

transferring that representation between components.

• It may be a HTML document or an image.

• Representation metadata and Resource metadata provides additional

information like media type, source link etc.

• Control data also defines the purpose of a message between components.

It can be used to manipulate cache behaviour.

• Media type defines the data format of a representation. The design of a

media type can directly impact the user-perceived performance of a distributed hypermedia system

• CONNECTORS :
• Connector types are used to encapsulate the activities of accessing

resources and transferring resource representations.

• A Client initiates communication by making a request e.g libwww.
• A Server listens for connections and responds to requests e.g Apache API.
• Cache connector may be used by a client or server to avoid repetition of

network communication e.g browser cache.

• A Resolver translates resource identifiers into the network address

information e.g. DNS look library.

• A Tunnel simply relays communication across a connection boundary e.g.

SOCKS.

• COMPONENTS :
• A User agent uses a client connector to initiate a request and becomes the

ultimate recipient of the response e.g. Web Browser.

• An Origin server uses a server connector to govern the namespace for a

requested resource e.g IIS.

• A Proxy component is an intermediary selected by a client to provide

interface encapsulation of other services, data translation, performance enhancement, or security protection e.g Gauntlet.

• A Gateway (a.k.a., reverse proxy) component is an intermediary imposed
• rigin server to provide an interface encapsulation of other services, for data

translation, performance enhancement, or security enforcement e.g Squid.

REST Architectural Views

• Process View : It defines interaction relationship among components by

revealing the path of data as it flows through the system.

• Connector View : A connector view of an architecture concentrates on the

mechanics of the communication between components.

• Connectors examine the resource identifier in order to select an appropriate

communication mechanism for each request.

• Data View : A data view of an architecture reveals the application state as

information flows through the components.

• A steady state has no outstanding request. It determines the user perceived

performance.

Experience and Evaluation

• REST Applied to URI -
• Uniform Resource Identifiers (URI) are both the simplest

element of the Web architecture and the most important.

• Redefinition of Resource - Identifier shouldn't change as Web

uses embedded identifiers rather than link servers.

• Manipulating Shadows - Representations of identified

resource are manipulated than resource itself.

• Remote Authoring – Mechanism of forward or manipulate

representations.

• Binding semantics – Semantics are a by-product of act of

assigning resource identifier.

• ReST mismatches in URI - It observe scenario like usage of user

information like ID's, treating Web like distributed system, developing mirroring.

• REST Applied to HTTP -
• Extensibilty – ReST support deployment of changes in already

deployed architecture.

• Protocol Versioning - Each connection on a request/response chain

can operate at its best protocol level in spite of the limitations of some clients or servers.

• The restriction says server cannot use those optional features of the

higher-level protocol.

• The seperation of parsing and forwarding rules.
• Deployment of new response codes.
• Upgrade - Upgrade header field in HTTP/1.1 allow client to advertise

its willingness for a better protocol while communicating in an older protocol stream.

• Self-descriptive Messages – It support intermediate processing of

interaction.

• Host - Addition of the target URL's host information within a Host

header field of the request message.

• Layered encoding - Transfer-encoding allows messages to be

encoded for transfer to describe the nature of message.

• Semantic Independence – Message parsing & forwarding is

seperated.

• Transport Independence - The chunked encoding allows

functionality to determine size of representation.

• Size Limits - It specifies limit within implementation of protocol.
• Cache control – It describes the details of data transferred.
• Content Negotiation – Selection among multiple representations

against a request. It can be Preemptive, Reactive, Transparent.

• Performance – It focus on improving user-percieved performance.

• Persistent connections uses length-delimited messages in order to

send multiple HTTP messages on a single connection.

• Disabling write back caching.
• REST Mismatches in HTTP -
• Differentiating Non-authoritative Responses.
• Cookies also violate REST because they allow data to be passed

without sufficiently identifying its semantics.

• Mixing Metadata – Unable to differentiate message control data &

representation metadata.

• Mime Syntax – HTTP use HTML as media type in reference to

package.

• DESIGN OF MEDIA TYPE -
• Incremental processing – HTML.
• Java vs Javascript.

Features of ReSTful Web Service

• RESTful Web Service is platform independent.

You do not have to worry if server runs MAC and client runs LINUX.

• RESTful Web Service is language independent

e.g. C# can talk to Java etc.

• RESTful Web Service applications use HTTP

requests to post data, read data and delete

• data. Thus, REST uses HTTP for all four CRUD

[CREATE, READ, UPDATE, DELETE]

• perations.

How RESTful Web Service service works ?

RESTful Web Service Request and Responses

Example of requests in RESTful Web Service & SOAP

• In the following e.g.,
• We are querying a phonebook application for the

details of a given user. All we have is the user's ID.

• In SOAP, The result is probably an XML file, but it will

be embedded, inside a SOAP response envelope.

• In REST, It's just a URL.
• This URL is sent to the server using a GET request,

and the HTTP reply is the raw result data -- not embedded inside anything.

Complex RESTful Web Service Request

REST can also handle more complex requests, including multiple parameters. GET request is used to read queries, POST request is given more preference when we use complex parameters or for creating, updating or deleting data.

RESTful Web Service Server Response

• Server response in REST is usually in XML

format. Unlike SOAP, REST isn't bound to XML. It can include other formats like CSV(Comma Seperated Values), JSON(Javascript Object Notation)

• Each format has its own features. XML is easy

to expand and is type-safe; CSV is more compact, JSON is easier to parse in other languages.

Example of a RESTful Web Service Server Response

A server response in REST in an XML file

Merit of RESTful Web Service

• Better cache support lightweight requests and responses.
• REST reduces network traffic.
• Other factor which makes REST useful is ease of implementation,

design, and the lightweight approach to things.

• SOAP RPC over HTTP, on the other hand, encourages each

application designer to define new, application specific methods that supplant HTTP methods.

RESTful Web Service Design Guideline

• Do not use "physical" URLs. A physical URL points at something

physical -- e.g., an XML file: "http://www.acme.com/inventory/product003.xml". A logical URL does not imply a physical file: "http://www.acme.com/inventory/product/003 ".

• Queries should not return an overload of data. If needed, provide a

paging mechanism. For example, a "product list" GET request should return the first n products (e.g., the first 10), with next/prev links.

• Even though the REST response can be anything, make sure it's well

documented, and do not change the output format lightly.

• GET access requests should never cause a state change. Anything

that changes the server state should be a POST request (or other HTTP verbs, such as DELETE).

RESTful Web Service Examples

• A simple example:

The following URL sends a REST request to Twitter's search service: http://search.twitter.com/search.atom? q=servicecomputing&count=2. This specific search request searches for the string "Servicecomputing", as set by the q parameter; and limits the response to at most 2 results, using the count parameter.

• Twitter has a REST API. https://dev.twitter.com/docs/api
• Flickr also has a REST API.

http://www.flickr.com/services/api/response.rest.html

Documentation for RESTful Web Service service

• RESTful Web Service use two patterns for documentation:

WSDL or WADL.

• WSDL 2.0 supports all HTTP verbs like PUT, DELETE.
• The Web Services Description Language is an XML-based

interface description language that is used for describing the functionality offered by a web service.

• WADL, Web Application Description Language by Sun

Microsystems.

• WADL is lightweight, easier to understand and easier to write

than WSDL. WADL is a machine-readable XML description of HTTP-based web applications.

Additional Resources

• REST API Design Rulebook, Mark Masse,

2011, O'Reilly Media, Inc.

• RESTful Web Services, Leonard Richardson

and Sam Ruby, 2008, O'Reilly Media, Inc.

• RESTful Web Services Cookbook, Subbu

Allamaraju, 2010, O'Reilly Media, Inc.

• REST in practice: Hypermedia and Systems

Architecture, Jim Webber, 2010, O'Reilly Media, Inc.