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
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
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
