Download - SOAP vs REST
SOAP vs RESTThen REST By Example
Why did REST popularity shot up?
• ReST has been there for a while…..
Quiz 3: What was the game changer…?
The Essential - RecapSOAP ReSTSimple Object Access Protocol Representational State Transfer
Protocols: HTTP, SMTP, UDP, TCP, JMS Protocols: Quiz1“Operations” model: getPrincipal(long)…etc.
Resource oriented (Investigation, Principal, etc…)A resource is identified by a Uniform Resource Identifier (uri)
Uses WSDL to define interface (contract)
Uniform interface: uses HTTP verbs (GET, etc..) Resources are manipulated via verbs and uniform interfaces
XML based message exchange XML, JSON, ATOM
Stateful( "Stateful" means that the server stores information about the client and uses that information over a series of requests)
Stateless ( Resources are stateless)
We already know SOAPMore on REST perfavore….
REST
Resources
Uniform Interface
Cacheable
Stateless
Linkability
Client Server
Resources• Everything is a resource• Resources are addressable via URIs (Uniform Resource Identifier)
Example: GET http://<pref>/principals/133519972001296
• Resources are self descriptive – Typically through content types (“application/xml”
“application/json”) – Resources are stateless
• Resources are manipulated via verbs and the uniform interface
Uniform Interface
Uniform
• GET(http://<pref>/principals/133519972001296)
• PUT(uri)• DELETE(uri)• POST (uri)
Non Uniform
• getPrincipal(id)• updatePrincipal(p)• deletePrincipal(id)• createPrinciPal(p)
Stateless• Each request from client to server must contain all of the information necessary to
understand the request (cannot take advantage of any stored context on the server) Session state is therefore kept entirely on the client
• This constraint 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. (ex: timeout)
➢ 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 request.
What are idempotent and/or safe methods?
• Safe methods are HTTP methods that do not modify resources. – For instance, using GET or HEAD on a resource URL, should NEVER change the resource
• Safe methods are methods that can be cached, pre-fetched without any repercussions to the resource
• An idempotent HTTP method is a HTTP method that can be called many times without different outcomes
Consider the following examples: a = 4; a++; The first example is idempotent: no matter how many times we execute this statement, a will always be 4. The second example is not idempotent. Executing this 10 times will result in a different outcome as when running 5 times. Since both examples are changing the value of a, both are non-safe methods -
Client Server continued….
Remember this picture…?
Client Server continued….
Applications in any language leveraging Services via REST API exposed by controller modules
Black Box -:)
From a consuming application perspective,this API defines the service contract
Client Server • Separation of concerns is the principle behind the
client-server constraints. • By separating the user interface (or any other
consuming client type) concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
• Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
“Cacheable” Resource and HTTP Cache (*)
HTTP has a Cache specification: http://tools.ietf.org/html/rfc2616#section-13What does have to do with REST…?Cacheable Constraint (*)
“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.Roy Fielding Network Cache
Benefits of Idempotent• building a fault-tolerant APISuppose a client wants to update a resource through POST. Since POST is not a idempotent method, calling it multiple times can result in wrong updates. What would happen if you sent out the POST request to the server, but you get a timeout. Is the resource actually updated? Does the timeout happened during sending the request to the server, or the response to the client? Can we safely retry again, or do we need to figure out first what has happened with the resource? By using idempotent methods, we do not have to answer this question, but we can safely resend the request until we actually get a response back from the server.Be careful when dealing with safe methods as well: if a seemingly safe method like GET will change a resource, it might be possible that any middleware client proxy systems between you and the server, will cache this response. Another client who wants to change this resource through the same URL (like: http://example.org/api/article/1234/delete), will not call the server, but return the information directly from the cache. Non-safe (and non-idempotent) methods will never be cached by any middleware proxie- See more at: http://restcookbook.com/HTTP%20Methods/idempotency/#sthash.F7V5Ga67.dpuf
Summary of Some HTTP Methods
HTTP Method Idempotent SafeOPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no
Hypertext and Linkability
●We don’t want “keys”, we want links!●Resources are hypertext
● Hypertext is just data with links to other resources
●Data model refers to other application states via links
●This is possible because of the uniform interface! No need to know different ways to get different types of entities!
●Consuming Client can simply navigate to different resources
Resourceshttp://jsonapi.org/http://restcookbook.com/http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf