2 Agenda REST Concept REST Constrains REST Data Elements REST V.S. SOAP How to be RESTfulQ&A
3 Representational State Transfer between Resource REST ConceptREST isRepresentational State Transfer between ResourceA style of software architectureA Virtual state-machineA network of web pages (a virtual state-machine),where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.Examples:Client-server modelEvent-driven architectureService-oriented architectureThree-tier modelFor distributed hypermedia systems such as the World Wide Web.Is not limited to the HTTP protocol.RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state.A style is a named set of constraints on architectural elements that induces the set of properties desired of the architecture.
4 REST Constraints Client-Server Separation principle Components IndependentStatelessSession state on the clientVisibility, reliability and scalabilityTrade off (network performance, etc.)CacheableA response can be cacheableEfficiency but reduce reliabilityLayered systemSystem scalabilityCode on demand (optional)Extension after deploymentUniform InterfaceSimpleClient-ServerImprove the portability of the user interface across multiple platformsImprove scalability by simplifying the server components.supporting the Internet-scaleStateless (to server)Request from client to server must contain all of the information necessary to understand the request,Session state is therefore kept entirely on the client.Induces the properties of visibility, reliability, and scalability.Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request.Reliability is improved because it eases the task of recovering from partial failures.Scalability is improved because not having to store state between requests allows the server component to quickly free resources,and further simplifies implementation because the server doesn't have to manage resource usage across requests.CacheableA response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.The trade-off, however, is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.Code on DemandREST 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.Allowing features to be downloaded after deployment improves system extensibility.However, it also reduces visibility, and thus is only an optional constraint within REST.LayeredThe 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.Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary.Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors.
5 REST Data Elements Resources and Resource Identifiers HTTP Method CRUD Uniform Interface (GET, PUT, POST, DELETE)Resource OrientedSimple and simple is beautifulHTTPMethodCRUDDesc.POSTCREATECreate-GETRETRIEVERetrieveSafe,Idempotent,CacheablePUTUPDATEUpdateIdempotentDELETEDeleteEach Resource has a URIA "collection of resources" may, in itself, be a whole new resource. E.g. a search result collection.In a system for maintaining an employee contact, each user should have their own URI with an appropriate representation.The collection of all employees is another resource. Dereferencing the URI: Agents may use a URI to access the referenced resource.safe : no side effect, The word "safe" means that if a given HTTP method is invoked, the resource state on the server remains unchangedThe word "idempotent" means that, regardless of how many times a given method is invoked, the end result is the same.GET is always safe. No matter how many times you download this web page, the contents of it will not change due to your repeated downloads, since you cannot change the web page in that way.PUT is not safe, because if you store something on the server, then you are creating a new resource or you are modifying a resource. (Of course, one might modify a resource to contain the same representation, but that is a corner case and not the general rule we apply to PUT.)DELETE is clearly not safe.POST is not safe. However, if POST is used to send an , then why would it not be considered safe? GET and HEAD are idempotent. PUT is also idempotent. If you issue PUT 100 times, the resource state on the server is exactly the same as if you use the PUT method one time.DELETE is also idempotent. If you delete a resource once, it is gone. One cannot delete it again and, if one tried, it would have obviously not make state changes to the resource, since there is no resource to change.
6 REST Data ElementsRepresentationsHTML / XML / images / sounds / …
7 REST V.S. SOAP SOAP Simple Object Access Protocol RPC protocol that go through firewallsCommunication protocol between applicationsA format for sending messagesApplications running on different operating systems, with different technologies and programming languagesOriginal RPC can not go through firewalls
8 REST V.S. SOAPREST“The Web is the universe of globally accessible information”Resource orientedUser-driven interactions via formsFew operations (generic interface) on many resourcesURI: Consistent naming mechanism for resourcesFocus on scalability and performance of large scale distributed hypermedia systemsSOAP“The Web is the universal transport for messages”Activity/Service orientedOrchestrated reliable event flowsMany operations (service interface) on few resourcesLack of standard naming mechanismFocus on design of integrated (distributed) applications- Applications running on different operating systems, with different technologies and programming languages
9 REST V.S. SOA Two of most common styles of use of Web Services Service-oriented architecture“Message oriented” (SOAP)Contract provided by WSDLRESTFocus on interacting with stateful resources, rather than messages or operations.non-RESTful Web services often complain that they are too complexBy contract, non-RESTful Web services easy to define new interfaces for remote interaction, often relying on introspection to extract the WSDL,since a minor change on the server (even an upgrade of the SOAP stack) can result in different WSDL and a different service interfaceOverlap??SOA using RESTful Web Services
10 REST V.S. SOA SOA principles REST principles Correlation Standardized Service ContractsService Loose CouplingService AbstractionService ReusabilityService AutonomyService StatelessnessService DiscoverabilityService ComposabilityREST principlesUnique identifiability of the resources through URIsUniform interface to access the resourcesNavigability of the resource representations through hypermediaStatelessnessCorrelationREST is an architectural style that inherently helps to attain some of the basic SOA principles.