QCon SF: Pete Lacey -- "Demonstrating the 'ilities' of REST"
November 8, 2007
These are my unedited notes from Pete Lacey’s talk “Demonstrating the ‘ilities’ of REST”.
- Agrees with everything Steve said, disagrees with almost everything Sanjiva said
- Degrees of RESTfulness - adding and removing constraints is perfectly fine
- for every constraint, there is a trade-off
- table showing constrains, properties, trade-offs
- topic: accessibility, a new “ility”, the sum of: simplicity, scalability/2 and modifiability/2
- scalability: both at runtime (1 million simultaneous clients) and ability to connect (500,000 to begin with)
- the ability to manipulate information as needed
- also a topic: modifiability (extensibility, evolvability, configurability, reusability, customizability)
- Rule #1: Everything of value is URI addressable
- Rule #2: see rule#1 - it’s that important
- URIs enable both versions of the Web
- they can be linked to written down, memorized, emailed, IMed, tagged, voted on
- information accesible to one degree or the other to anyone: managers, shadow IT, proto-geeks and mom
- systems can be extended simply by adding new resources
- use descriptive URIs for human accesibility
- Client developers should treat URIs as opaque: code shot not assemble URIs based on a perceived pattern. does not conflict with descriptive URIs (as they are for human usage)
- Rule #4: the self-descriptive messages constraint
- media types should be selected so that the maximum number of clients can participate
- strongly consider XHTML
- consider multiple representation formats
- suggestion to use custom MIME types
- XML namespaces is not an alternative, especially because they can’t be sniffed (they might be at lower levels of the document)
- JSON, Atom feeds, PDFs, images, audio (where no MTOM, SwA, DIME etc. is required)
- consider unique resources for each representation - content negotiation hasn’t worked out as well: UIs, especially browsers don’t allow to modify Accept headers
- learn and use HTTP headers
- a message is more than the entity body (Accept-*, Content-type, location, last-modified, etags, expires/cache-control)
- renewed recommendation to use XHTML: it’s not simply a display format
- XHTML is real XML - parseable, XPathable, XQueryable, XCeterable
- more accessible
- information available to anyone with a browser (IE issues aside)
- has useful constructs for links, lists, name/value pairs
- graceful degradation
- class, rel,e tc. provide semantic value
- consider returning stylesheets and nicely formatted pages too - honored by browsers, ignored otherwise
- diversion of microformats
- reference to http://microformats.org
- Rule #5: the uniform interface constraint (description of safety & idempotence of GET, PUT, POST, DELETE)
- Rule #6: more on the uniform interface constraint - use HTTP response codes
- Corollary to rules 1-6: DON’T create one or a few URLs and overload them
- Client authors can no longer assume HTTP semantics - each URI is accessible via a unique networking protocol
- if it’s not on the Web, it doesn’t exist
- demo of “ilities” using a sample expense reporting system
- picking on Sanjiva’s line: are you smart enough to build a RESTful system? yes!
- a mental leap is required to switch from methods/operations to REST
- (comments while demoing a Rails app)
- The URL to a RESTful API should lead the developer to a Web app
- Glen: Doesn’t having an “edit” operation in URI not conflict with the statement that there shouldn’t be a method in the URI?
- Pete: First, HTML forms don’t support PUT and DELETE
- “edit” identifies the HTML form
- HTML 4 requires compromises, HTML 5 will support PUT and DELETE
- Pete claims Rails puts in a PUT or DELETE via Javascript (I don’t think so)
- shows XML version of appending .xml at the end
- switches on a little FireFox plugin that shows HTTP headers
- shows microformat for hCal to demo accessibility increase
- Question/Comment: you can use cookies and still be RESTful, if you don’t use sessions
- Answer: the hard thing is cookies can have any meaning, because of this intermediaries might decide to not cache
- Suggestion to avoid cookies, rely on HTTP authentication
- discussion about whether or not HTTP authentication
- shopping carts in the 90s were built using sessions - the RESTful way is to use resources
- shows HTML source, including semantically marked up calendar stuff
- switches to Excel, uses “Import external data”, enters collection resource URI, pulls stuff from XHTML table to Excel
- (Excel takes ages?)
- switches to Word, uses Inser Field, IncludeText, Reference, gets expense reports in both clients
- Excel and Word as examples of clients of my API without any knowledge before
- shows how web-based feed reader can retrieve data from the app
- Prompted by Patrick Logan, Pete agrees REST has pretty good tooling
- don’t underestimate how much debugging with your browser helps
- shows demo curl command line. (Weak, he had it in a script. I always actually type them in :-))
- Windows Active Desktop! showing XHTML
- slides again: a Web application is a RESTful application
- Rule #7: “The hypermedia as the engine of app … oh, never mind. The hypertext constraint”
- copious links to other related data and to guide clients through the app
- allow for URIs to change
- allow for clients to dynamically determine what to do next
- allows for clients to discover resources
- allow for independence of location and security boundaries
- Adapted from Stu Charlton: forms with GET are just links
- shows simple Ruby client that uses XPath to extract data and act on it
- (lightly abrupt ending because the time was up)
About
This page contains a single entry from Stefan Tilkov's Random Stuff posted on November 8, 2007 11:48 PM. The previous post in this blog was QCon SF: Steve Vinoski -- REST Eye for the SOA Guy. The next post in this blog is QCon SF: Dan Diephouse -- "Building your next service with the Atom Publishing Protocol". Many more can be found on the main index page or by looking through the archives.