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 of 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 on 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 origin 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] operations.
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.