Introduction to REST
•Download as PPT, PDF•
0 likes•503 views
This document provides an introduction to REST (Representational State Transfer), including: - REST concepts like using resources and URIs to transfer representations between client and server using standardized HTTP methods. - REST constraints like being stateless, cacheable, and having a uniform interface. - How REST differs from SOAP by being resource-oriented rather than activity-oriented and focusing on scalability over reliability. - How REST aligns with service-oriented architecture principles like loose coupling and reusability through its use of standardized contracts and statelessness.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Introduction to REST
Similar to Introduction to REST (20)
More from kumar gaurav
More from kumar gaurav (20)
Recently uploaded
Recently uploaded (20)
Introduction to REST
- 2. Agenda REST Concept REST Constrains REST Data Elements REST V.S. SOAP REST V.S. SOA How to be RESTful Q&A
- 3. REST Concept REST is Representational State Transfer between Resourcebetween Resource A style of software architecture A Virtual state-machine A 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.
- 4. • Client-Server • Separation principle • Components Independent • Stateless • Session state on the client • Visibility, reliability and scalability • Trade off (network performance, etc.) • Cacheable • A response can be cacheable • Efficiency but reduce reliability • Layered system • System scalability • Code on demand (optional) • Extension after deployment • Uniform Interface • Simple REST Constraints
- 5. • Resources and Resource Identifiers • Uniform Interface (GET, PUT, POST, DELETE) • Resource Oriented • Simple and simple is beautiful REST Data Elements HTTP Method CRUD Desc. POST CREATE Create - GET RETRIEVE Retrieve Safe,Idempotent,Cacheable PUT UPDATE Update Idempotent DELETE DELETE Delete Idempotent
- 6. Representations • HTML / XML / images / sounds / … REST Data Elements
- 7. SOAP • Simple Object Access Protocol • RPC protocol that go through firewalls • Communication protocol between applications • A format for sending messages REST V.S. SOAP
- 8. REST •“The Web is the universe of globally accessible information” • Resource oriented • User-driven interactions via forms • Few operations (generic interface) on many resources • URI: Consistent naming mechanism for resources • Focus on scalability and performance of large scale distributed hypermedia systems SOAP •“The Web is the universal transport for messages” • Activity/Service oriented • Orchestrated reliable event flows • Many operations (service interface) on few resources • Lack of standard naming mechanism • Focus on design of integrated (distributed) applications REST V.S. SOAP
- 9. Two of most common styles of use of Web Services •Service-oriented architecture • “Message oriented” (SOAP) • Contract provided by WSDL •REST • Focus on interacting with stateful resources, rather than messages or operations. REST V.S. SOA
- 10. REST V.S. SOA Correlation • REST is an architectural style that inherently helps to attain some of the basic SOA principles. SOA principles •Standardized Service Contracts •Service Loose Coupling •Service Abstraction •Service Reusability •Service Autonomy •Service Statelessness •Service Discoverability •Service Composability REST principles •Unique identifiability of the resources through URIs •Uniform interface to access the resources •Navigability of the resource representations through hypermedia •Statelessness
Editor's Notes
- 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 model Event-driven architecture Service-oriented architecture Three-tier model For 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.
- Client-Server Improve the portability of the user interface across multiple platforms Improve scalability by simplifying the server components. supporting the Internet-scale Stateless (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. Cacheable A 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 Demand 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. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility, and thus is only an optional constraint within REST. Layered 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. 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.
- Each Resource has a URI A "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 unchanged The 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 e-mail, 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.
- Applications running on different operating systems, with different technologies and programming languages Original RPC can not go through firewalls
- - Applications running on different operating systems, with different technologies and programming languages
- non-RESTful Web services often complain that they are too complex By 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 interface Overlap?? SOA using RESTful Web Services