Your SlideShare is downloading. ×
0
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Rest on steroids
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rest on steroids

322

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
322
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. REST on steroids By Andrei Nefyodov
  2. Representational State Transfer(REST) — set of architectural constraintsConstraint Promotes At the expense ofClient-server ●UI portability ●Simplified server ●Multiple organizational domainsStateless ●Simplifiied server Efficiency ● ●Scalability ●ReliabilityOptional non-shared ●Reduced latency Reliability ●caching ●Efficiency ●ScalabilityUniform interface ●Visibility Efficiency ● ●Independent evolution ●Decoupled implementationLayered system ●Shared caching Higher latency ● ●Legacy encapsulation ●Simplified clients ●Scalability ●Load balancingOptional code-on-demand ●Simplified clients Visibility ● ●Extensibility
  3. Representational State Transfer(REST) — set of architectural constraintsConstraint Promotes At the expense of Sub-constraints:Client-server ●UI portability ● Identification of resources ●Simplified server ● Manipulation via representations ●Multiple organizational domains ● Self-descriptive messages ● Hypemedia as the engine of application stateStateless ●Simplifiied server ●Efficiency ●Scalability ●ReliabilityOptional non-shared ●Reduced latency ●Reliabilitycaching ●Efficiency ●ScalabilityUniform interface ●Visibility ●Efficiency ●Independent evolution ●Decoupled implementationLayered system ●Shared caching ●Higher latency ●Legacy encapsulation ●Simplified clients ●Scalability ●Load balancingOptional code-on-demand ●Simplified clients ●Visibility ●Extensibility
  4. Representational State Transfer(REST) — set of architectural constraintsConstraint Promotes At the expense of Sub-constraints:Client-server ●UI portability ● Identification of resources ●Simplified server ● Manipulation via representations ●Multiple organizational domains ● Self-descriptive messages ● Hypemedia as the engine of application stateStateless ●Simplifiied server ●Efficiency ●Scalability ●ReliabilityOptional non-shared ●Reduced latency ●Reliabilitycaching ●Efficiency ●ScalabilityUniform interface ●Visibility ●Efficiency ●Independent evolution ●Decoupled implementation You get these ifLayered system ●Shared caching you use HTTP latency ●Higher ●Legacy encapsulation as your application protocol ●Simplified clients ●Scalability ●Load balancingOptional code-on-demand ●Simplified clients ●Visibility ●Extensibility
  5. Representational State Transfer(REST) — set of architectural constraintsConstraint Promotes At the expense of Sub-constraints:Client-server ●UI portability ● Identification of resources ●Simplified server ● Manipulation via representations ●Multiple organizational domains ● Self-descriptive messages ● Hypemedia as the engine of application stateStateless ●Simplifiied server ●Efficiency ●Scalability ●ReliabilityOptional non-shared ●Reduced latency ●Reliabilitycaching ●Efficiency ●ScalabilityUniform interface ●Visibility ●Efficiency ●Independent evolution ●Decoupled implementationLayered system ●Shared caching ●Higher latency ●Legacy encapsulation ●Simplified clients ●Scalability ●Load balancingOptional code-on-demand ●Simplified clients ●Visibility ●Extensibility
  6. Hypermedia● Links in representations● State navigations discoverable HATEOAS — hypertext as the engine of application state. We express allowed state transitions through links.
  7. ● Hypermedia constraint is an often-overlooked part of being RESTful● Using Hypermedia aware media type such as collection+json, XHTML promotes➢ Loose coupling between client and server➢ Simple documentation of semantic concepts➢ Discoverability / testability / operability via «API surfing»● Much of the client framework is reusable
  8. ● RESTBucks● Starbucks (like) coffee ordering● Order/payment 5 6 Preparing Ready Completed 4 21 Payment expected 3 Cancelled
  9. Method URI Action StepPOST /orders Create new order 1PUT/PATCH /orders/4711 Update the order 2 (only if «payment expected»)DELETE /orders/4711 Cancel order 3 (only if «payment expected»)PUT /orders/4711/payment Pay order 4 Barista preparing the orderGET /orders/4711 Poll order state 5GET /orders/4711/receipt Access recieptDELETE /orders/4711/receipt Conclude the 6 order process
  10. ChallengesHow to avoid hard coding URIs?
  11. Use link relations
  12. Orders Returns all orders available in the systemOrder Returns a single orderSelf The uri value can be used to GET the latest resource representation of the order.Cancel This is the URI to be used to DELETE the order resource should the consumer wish to cancel the order.Update Consumers can change the order using a POST to transfer a representation to the linked resource.Payment The linked resource allows the consumer to begin paying for an order. Initiating payment involves PUTting an appropriate resource representation to the specified URI.Receipt The URI to access the receipt using GET and conclude the order by taking the receipt (use DELETE).
  13. Method Relation type Action StepPOST orders Create new order 1PUT/PATCH update Update the order 2 (only if «payment expected»)DELETE cancel Cancel order 3 (only if «payment expected»)PUT payment Pay order 4 Barista preparing the orderGET order Poll order state 5GET receipt Access recieptDELETE receipt Conclude the 6 order process
  14. ChallengesHow to implement «only if paymentexpected»?
  15. We can only navigate a link once it wasreturned by the server
  16. Place order● Access root resource { links : [ { rel : "orders", href : "…/orders" }] }● Follow orders link $.links[?(@.rel="orders")].href● POST /orders
  17. { links : [{ rel : "self", href : "…/orders/4711" }, … … { rel : "payment", href : "…/orders/4711/payment" } ], content : { items : [{ drink : "Cappucino", size : "large", milk : "semi" price : 4.2 } ], location : "take-away", price : 4.2 status : "payment expected" }}
  18. Trigger payment● Follow payment link● $.links[?(@.rel="payment")].href● PUT /orders/4711/payment
  19. { links : [{ rel : "self", href : "…/orders/4711/payment" }, { rel : "order", href : "…/orders/4711" } ], content : { creditCard : [{ number : "1234123412341234", cardHolder : "Ivan Ivanov", expiryDate : "2013-11-01" } ], amount : { currency : "EUR", value : 4.2 } }}
  20. Poll order● Follow order link $.links[?(@.rel="order")].href● GET /orders/4711● ETag / If-None-Match
  21. { links : [{ rel : "self", href : "…/orders/4711" } ], content : { items : [{ drink : "Cappucino", size : "large", milk : "semi" price : 4.2 } ], location : "take-away", price : 4.2 status : "preparing" }}
  22. { links : [{ rel : "self", href : "…/orders/4711" }, { rel : "receipt", href : "…/orders/4711/receipt" } ], content : { items : [{ drink : "Cappucino", size : "large", milk : "semi" price : 4.2 } ], location : "take-away", price : 4.2 status : "ready" }}
  23. Access receipt● Follow receipt link● $.links[?(@.rel="receipt")].href● GET /orders/4711/receipt Conclude order● Follow receipt link● $.links[?(@.rel="receipt")].href● DELETE /orders/4711/receipt
  24. DEMO
  25. Summary● Hypermedia — is often overlooked constaint of REST. In exchange you get independent evolution and decoupled implementation.● Spring HATEOAS - http://bit.ly/spring-hateoas● Representation models● LinkBuilderAPI● Representation enrichment● Spring Data REST - http://bit.ly/sd-rest● Exports JPA repositories as resources● Hypermedia driven representations● Extension points● REST Shell - github.com/SpringSource/rest-shell● Explore REST webservices● Hypermedia driven● Spring HATEOAS link format● Spring RESTBucks - http://bit.ly/spring-restbucks● Sample implementation● Using Spring technologies● Lombok — projectlombok.org• get rid of boilerplate
  26. QUESTIONS?

×