You need to REST

You need to REST

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

E2143258b0228b454fa4b63d406243f3?s=128

Avinash Chugh

June 13, 2013
Tweet

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