16
SOAP vs REST Then REST By Example

SOAP vs REST

Embed Size (px)

Citation preview

Page 1: SOAP vs REST

SOAP vs RESTThen REST By Example

Page 2: SOAP vs REST

Why did REST popularity shot up?

• ReST has been there for a while…..

Quiz 3: What was the game changer…?

Page 3: SOAP vs REST

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)

Page 4: SOAP vs REST

We already know SOAPMore on REST perfavore….

REST

Resources

Uniform Interface

Cacheable

Stateless

Linkability

Client Server

Page 5: SOAP vs REST

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

Page 6: SOAP vs REST

Uniform Interface

Uniform

• GET(http://<pref>/principals/133519972001296)

• PUT(uri)• DELETE(uri)• POST (uri)

Non Uniform

• getPrincipal(id)• updatePrincipal(p)• deletePrincipal(id)• createPrinciPal(p)

Page 7: SOAP vs REST

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.

Page 8: SOAP vs REST

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 -

Page 9: SOAP vs REST

Client Server continued….

Remember this picture…?

Page 10: SOAP vs REST

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

Page 11: SOAP vs REST

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.

Page 12: SOAP vs REST

“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

Page 13: SOAP vs REST

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

Page 14: SOAP vs REST

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

Page 15: SOAP vs REST

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

Page 16: SOAP vs REST

Resourceshttp://jsonapi.org/http://restcookbook.com/http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf