You need to REST

Building out a case for embracing the architecture of the web.

Transcript

1. You need to REST Embrace the architecture of the web
2. Agenda Distributed Systems SOA paradigms WS-* REST Real-world APIs Conclusions
3. Distributed Systems System A System B System C Organization Across application boundaries
4. Distributed Systems System A System B Organization A System X System Y Organization B Across organization boundaries
5. Monolithic applications Data Application Domain Logic UI Pros: Less complex Easier to deploy Cons: Hard to maintain Higher coupling Hard to scale
6. How do we get various monolithic applications to talk?
7. Share data Application A Application B Application C Database Export
8. Share objects over the network Application A Application C Application B Application D Bus
9. Modular architecture Application C Application B Application A Service 1 Service 2 Database 1 Database 2 ...
10. Pros & Cons Separation of concerns Reusable Less coupling Can evolve to meet the needs of the business More options for scaling More complex More layers of software Slow to start off Needs partitioning
11. Domain Partitioning Logical Function Iteration speed Read-Write Frequencies Join Frequency
12. Service-oriented architecture A modular style to software construction that is based on loosely-coupled, distributed, and replaceable components (aka. services).
13. web services functional building blocks accessible over standard internet protocols
14. benefits Allows different systems to interoperate Encourages reuse across multiple applications Enables services to evolve independently Need not be tied to specific implementation Easier to scale portions of the system Compose applications out of existing services
15. Web services paradigms WS-* RPC-style consumption of WS-* compliant services over XML-like messaging framework (SOAP) REST Transfer/manipulate representations of (addressable) resources over HTTP
16. First-generation web-services UDDI WSDL SOAP Web services is accessed using enables discovery of binds to enables communication between describes
17. Next-generation web-services WS-* in action http://www.servicetechspecs.com/images/ws-diagram2b.jpg
18. WS-* is simple? http://www.innoq.com/soa/ws-standards/poster/
19. WS-* is useful? “Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby, and PHP. You won’t see them, because there’s no intrinsic value in WS-*, unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates 'value' that can be sold.” Mark Nottingham, one time chair of WS-Addressing working group
20. http://blog.adnanmasood.com/wp-content/uploads/2012/05/WCF-is-not-SOA.jpg
21. “WSDL is the single most damaging technology in the Web Services space today, not only because it is complex and unwieldy, but also because it supports an inherently unsuitable model for Internet-scale systems. WSDL-based toolkits make choosing inappropriate engineering decisions easy, which substantially increases technical risk when using the WS-* stack.” -Rest in Practice
22. Instead... “REST-ful HTTP moves you closer to SOA than WS-*.” Stefan Tilkov, Co-founder at InnoQ, Author of “Rest und HTTP”
23. http as an application protocol ...rather than just a transport protocol Principal HTTP verbs describe important changes to application state GET, PUT, POST, & DELETE (a bit like CRUD in databases) ...and if you can’t, think about if the application should be on the web.
24. name states rather than actions ...or prefer nouns to verbs nouns ~ objects; verbs ~ messages URIs name application states; You manipulate representations Similar to OO-design where the verbs have been already picked out for you.
25. exploit http, everyone else does Service Consumer Service Provider request response method GET /orders/1234 HTTP/1.1 headers Host: starbucks.example.com Accepts: application/json HTTP/1.1 200 OK headers Content-Type: application/json Content-Length: 425 { "drink": "latte", "cost": 3.50, "links": [ { "rel": "self", "href": "http://starbucks.example.com/ orders/1234" }, { "rel": "payment", "href": "http:// starbucks.example.com/orders/1234/payment" }, { "rel": "cancel", "href": "http:// starbucks.example.com/orders/1234/cancel" }, ... ] } Request Response URI status body hypermedia
26. exploit http, everyone else does GET POST PUT DELETE MOVE COPY HEAD OPTIONS 200 OK 201 Created 202 Accepted 304 Not modified 400 Bad request 404 Not found 409 Conflict 500 Internal Server Error safe unsafe idempotent idempotent safe safe http verbs http status codes
27. Principles of REST Give everything an “id” (global, permanent) Each resource is uniquely identified; A resource may have several representations (e.g. html, json, xml) Manipulate resources through their representations Use the standard HTTP verbs to manipulate the resources Hypermedia as the engine of application state * Resources can include links that let consumers discover possible state transitions Self-descriptive messages Separation of control from the data allows for layered architecture; the non-functional requirements can be deferred to the intermediaries. *Clients should have prior knowledge of the service media-types
28. Security Advanced WS-* standards are overrated HTTP + SSL is adequate for most situations Message security is expensive Ensure eligible clients can consume the service
29. Scalability Stateless requests means they need not be bound to a specific server. Also lets you constrain services on an individual basis. Client Load Balancer Server1/MyService Server2/MyService Server3/MyService
30. Scalability • HTTP Get’s are safe, idempotent, and therefore cacheable • WS-* (tunneling over HTTP post) - not safe, not idempotent, and therefore never cacheable • Support conditional GETs (If-modified-since, E-Tags) Client Load Balancer Cache Cache-control: public, max-age = 600
31. Caching “The best requests are those that never have to reach me.” (anonymously-overloaded server)
32. Fault tolerance The standard interface for REST lets the intermediaries make decisions on how to deal with failover. Client Load Balancer Cache 200 OK 500 Internal Server
33. Other concerns Service discovery UDDI Registry (WS-*) vs. embedded links (REST) Management /Auditing Web Services for Distributed Data Management (WS-*) vs. intermediary logs (REST) Reliability WS-ReliableMessaging (WS-*) vs. reliable business process (REST) Transactions WS-Transactions (WS-*) vs. no place in distributed, unreliable environments (REST)
34. Real-world APIs Rest-based APIs are widely deployed and used
35. Parting thoughts WS-* based systems tend to be overly-coupled and brittle HTTP/1.1 is a good application protocol REST offers a proven, viable model for architecting distributed systems. REST requires a paradigm shift from RPC APIs to generate/consume REST are widely available
36. “In reality, the effort required to design things is inversely proportional to the simplicity of the result.” Roy Fielding Author of seminal dissertation on REST “Architectural Styles and the Design of Network-based Software Architectures”
37. Questions?
38. Credits Modular vs. Monolithic - Pablo Astigarraga https://speakerdeck.com/pote/modular-vs-monolithic-porto-alegre Service-oriented architecture - Shalva Usobov https://speakerdeck.com/shaliko/service-oriented-architecture How to GET a Cup of Coffee - Webber, Parastatidis, Robinson http://www.infoq.com/articles/webber-rest-workflow Rest Assured - Hypermedia APIs with Spring - Oliver Gierke https://speakerdeck.com/olivergierke/hypermedia-apis-with-spring-2 Rest as better web service paradigm - Norman Gray http://wiki.ivoa.net/internal/IVOA/InterOpMay2007GridAndWebServices/talk-gray-rest.pdf Take a REST! - Cyril Rohr https://speakerdeck.com/crohr/take-a-rest