Rest in a Nutshell 2014_05_27
•Download as PPTX, PDF•
0 likes•720 views
This document summarizes REST (Representational State Transfer) and some of its key principles. It discusses the simplicity of single component services, distributed system architectures like RPC and distributed file/data stores. It also covers the uniform interface of REST, including methods, headers, status codes, content negotiation, and authentication. The document notes that REST emphasizes a uniform interface between components to distinguish it from other network-based styles.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Rest in a Nutshell 2014_05_27
Similar to Rest in a Nutshell 2014_05_27 (20)
More from Derrick Isaacson
Recently uploaded
Recently uploaded (20)
Rest in a Nutshell 2014_05_27
- 1. REST in a Nutshell By Derrick Isaacson
- 2. Can I get that without the bacon? Said no one ever http://www.food.com/photo-finder/all/bacon?photog=1072593
- 5. Simplicity of Single Component Services • I can’t remember if that getter function takes 100ns or 100ms. - Said no engineer ever • Should I try to model this server request as a “remote procedure call”? • 6 orders of magnitude difference! • My front-side bus fails for only 1 second every 17 minutes! - Said no engineer ever • 99.9% availability • Our internet only supports .NET. - Said no engineer ever • Do we need an SDK?
- 6. "A distributed system is at best a necessary evil, evil because of the extra complexity... An application is rarely, if ever, intrinsically distributed. Distribution is just the lesser of the many evils, or perhaps better put, a sensible engineering decision given the trade-offs involved." -David Cheriton, Distributed Systems Lecture Notes, ch. 1
- 7. Distributed System Architectures Does it have to be “Service-oriented”?
- 10. Distributed File System mount -t nfs -o proto=tcp,port=2049 nfs-server:/ /mnt
- 11. Distributed Data Stores • Replated MySQL • Mongo • S3 • RDS • BigTable • Cassandra …
- 12. P2P
- 13. Streaming Media
- 15. “There is no magic dust that makes an HTTP request a web service request.” -Leonard Richardson & Sam Ruby, RESTful Web Services
- 16. Representational State Transfer An Observation by Roy Fielding
- 18. Which Architectures Featured… 1. Low entry-barrier 2. High performance in the face of distributed state 3. Huge (Internet) scale 4. Extensibility/evolvability (backwards compatibility)
- 19. Uniform Interface 1. Uniform identification of resources 2. Uniform resource manipulation 3. Representation separate from the identity 4. Hypermedia as the engine of application state 5. Self-descriptive messages
- 20. HTTP Request
- 21. HTTP Response
- 23. Hypermedia GET /users/123 What would Roy say about this design? roy.gbiv.com { id : "123", name : "John Smith", phone : "303-404-5050", email : "john@example.com", photo : "YWZzYSAyMzR2NQzJ2dzLmZhc20uLC8uLA==", groups : [ { name: "Super Friends" members: [ ... ] } ], books : [ { name : "RESTful Web Services", description : "Fun times", publishDate : "2013-01-01 13:05:06" }, ... ] }
- 24. Hypermedia { id : "123", name : "John Smith", phone : "303-404-5050", email : "john@example.com", photo : "YWZzYSAyMzR2NQzJ2dzLmZhc20uLC8uLA==", groups : [ { name: "Super Friends" members: [ ... ] } ], books : [ { name : "RESTful Web Services", description : "Fun times", publishDate : "2013-01-01 13:05:06" }, ... ] } { id : "http://example.com/users/123", name : "John Smith", phone : "303-404-5050", email : "john@example.com", photo : "http://flickr.com/photos/12345", groups : [ "http://facebook.com/groups/abc", ... ], books : [ "http://goodreads.com/books/4567", "http://example.com/manuscripts/123", ... ] }
- 25. SDK Anti-pattern Where's my SDK? "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state... [Failure here implies that out-of-band information is driving interaction instead of hypertext.]" - Roy Fielding
- 26. Casserole Anti-pattern POST /groups HTTP/1.1 Content-Length: 1234 ObjectType: json { method : "UPDATE", id : "123" authToken : "abc123", object : { group : { ... } } } HTTP/1.1 500 Internal Server Error Content-Length: 456 { cacheTime : 0, status : "authorization failed" }
- 27. Uniform Interface: Methods Method Safe Idempotent OPTIONS GET HEAD POST PUT DELETE TRACE PATCH CONNECT* * Reserved for use of SSL tunneling
- 28. GET /service/customers/123 HTTP 1.1 Host: example.com User-Agent: XYZ 1.1 Accept: text/html, application/xhtml+xml,application/xml Keep-Alive: 300 Connection: keep-alive If-Modified-Since: Fri, 02 Oct 2013 16:47:31 GMT If-None-Match: "600028c-59fb-474f6852c9dab" Cache-Control: max-age=60 HTTP/1.1 200 OK Date: Sun, 04 Oct 2013 19:36:25 GMT Server: Apache/2.2.11 (Debian) Last-Modified:Fri, 02 Oct 2013 16:48:39 GMT Etag: "600028c-59fb-474f6852c9dab" Cache-Control: max-age=300 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 7160 Keep-Alive: timeout=15,max=91 Connection: Keep-Alive Content-Type: application/xml Uniform Interface: Headers (self-descriptive messages)
- 29. My pizza has too much cheese and toppings Said no one ever http://upload.wikimedia.org/wikipedia/commons/6/60/Pizza_Hut_Meat_Lover's_pizza_3.JPG
- 30. GET /service/customers/123 HTTP 1.1 Host: example.com User-Agent: XYZ 1.1 Accept: text/html, application/xhtml+xml,application/xml Keep-Alive: 300 Connection: keep-alive If-Modified-Since: Fri, 02 Oct 2013 16:47:31 GMT If-None-Match: "600028c-59fb-474f6852c9dab" Cache-Control: max-age=60 HTTP/1.1 200 OK Date: Sun, 04 Oct 2013 19:36:25 GMT Server: Apache/2.2.11 (Debian) Last-Modified:Fri, 02 Oct 2013 16:48:39 GMT Etag: "600028c-59fb-474f6852c9dab" Cache-Control: max-age=300 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 7160 Keep-Alive: timeout=15,max=91 Connection: Keep-Alive Content-Type: application/xml My message is too self- descriptive Said no one ever
- 31. Uniform Interface: Status Status-Code Reason-Phrase 200 OK 201 Created 202 Accepted 301 Moved Permanently 400 Bad Request 403 Forbidden 404 Not Found 405 Method Not Allowed 500 Internal Server Error
- 32. Uniform Interface: Error Codes • 400s vs 500s • Safe to retry? • Cacheable (if no Cache-Control header present)? • Does the client need to modify the request?
- 33. Inaccurate Status Codes HTTP/1.1 200 OK { error: true }
- 34. Uniform Interface: Content-Type Negotiation Request header: Accept Content-Types accepted by client Accept: text/*, text/html, text/x-vcard, application/json More specific types take precedence. Server responds with 406 Not Acceptable if it does not support the requested media type(s). Server responds with 415 Unsupported Media Type if it does not support the request entity’s media type.
- 35. Uniform Interface: Authentication How does a server prevent unauthorized access? 1. Authorization: Fooauth abc123= 2. Authentication-Info: mytype RFC 2617 Over-engineered narrowly-defined mumbo jumbo?
- 36. “The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.”
- 38. “WOW My system has too much uniformity, loose coupling, and performance.” -said no one ever
Editor's Notes
- Multiple nodes computing on inconsistent state with regular communication failures present entirely different challenges than those computer science students face in the classroom writing DFS algorithms.
- Idea: Nothing’s more familiar to programmers than reading from and writing to memory? We access variables all day long. Why not make distributed state access look like simple memory access? We can use modern operating systems’ support for virtual memory to “swap in” memory that is located on another machine. Problem: How often do you go to access a variable and can’t because a section of memory is “down”? How do you provide a mutex to parallel threads of execution? How can the distributed memory layer be efficient when it has no knowledge of the application?
- Idea: Next to memory access, nothing’s more familiar to programmers than functional calls. Can we make distributed state transfer look like a simple procedure call? SOAP! Problems: How often do you retry a method call because the JVM failed to invoke it the first time? Why does incrementing a value take 100 milliseconds? Why does your internet only support .NET and PHP (stub compiler/SDK)?
- Idea: Easy network file sharing. NFS, AFS, GFS Works great for files.
- Idea: Easy network file sharing. NFS, AFS, GFS Works great for files.
- Idea: How could you mooch bandwidth from universities and avoid infringement lawsuits at the same time? Problems: Mooching resources is a great business model but a terrible architecture if that’s not what you’re going for.
- Idea: I have so much state I don’t want to transfer it all in a single response.
- This is something I first learned reading Richardson & Ruby’s insightful “RESTful Web Services” book. There’s really nothing special about web services. HTTP is an application layer protocol. A common mistake that results in brittle, RPC-style web services is the use of HTTP as a transport layer for some other homegrown application protocol.
- At Lucidchart we’re moving toward the REST architectural style, and one of the reasons is that it gives us an adaptable and evolvable architecture. In the year 2000 Roy Fielding published his dissertation “Architectural Styles and the Design of Network-based Software Architectures”. In it he studies various architectural styles and analyzes why the web was so successful. Roy surveyed these application architecture designs to discover which were effective at four specific goals: Low entry-barrier Distributed hypermedia Internet-scale Extensibility Quickly summarizing three of the goals: 1. Looking at the goal low barrier to entry we see it is updated and managed by various entities independently, using many platforms, and being highly available to content authors and managers even when some pieces are down. 2. Hypermedia requires that presentation and control info be transferred to and from a client. Roy analyzed why the web is so successful at creating a performant application with hypermedia. 3. The Web’s accomplishment in achieving internet scale is incredible. The final goal of extensibility is where we’ll spend the rest of our time.