This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

QCon SF: Pete Lacey -- "Demonstrating the 'ilities' of REST"

Stefan Tilkov,

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)