Here are my raw, unedited notes from Leonard Richardson's QCon San Francisco 2008 talk.
- Advocating for a RESTful approach induces people to think you're crazy!
- Many application protocols in use on the Intenet - Web technologies were all seen as one big lump
- The Web obliterated all but a handful of Internet protocols (except: SMTP, BitTorrent, ssh, IRC and friends)
- Some protocols were simply never born because of the Web
- SOAP allows automated clients to get things done over HTTP, just like humans get stuff over HTTP
- But SOAP jumped on the HTTP bandwagon and HTTP < WWWW
- Some Web services are not RESTful, merely anti WS-*
- Use the whole Web - URI, HTTP, HTML - don't need to invent new specialised protocols now
- The Web is one big technology, made of 3 smaller technologies, and there are emergent properties
- Easy to buy high order arguments like HATEOAS if the upshot is that things get done faster
- Outvoted when trying to use Atom and AtomPub - use JSON with hyperlinks in the representations to explore the object graph, using a naming convention
- HTML and WADL may be isomorphic in general
- Question: is this (HTML/WADL) the equivalent of WSDL? Answer: Yes, probably.
- Backend implementation decisions can cause ugly hacks - uniform interface violations - that leak through the interface (e.g. bug status). PUTs being tunnelled through POST in this case
- Again, custom named operations through POST require more annotations
- Trying to avoid situations where a Web service changes and clients break (e.g. Amazon, WSDL-based services), turn to HATEOAS instead
- launchpadlib doesn't break when Web service changes
- warts on a Web service cause warts on the client! Specialised code needed, idioms sacrificed
- Every time a REST principle was violated, we paid the price on the client side. The hacks bled through to the client
- Use WADL to automatically generate human documentation
- You can judge a service crudely, by seeing how far it goes up the stack: URI->HTTP->HTML (hypermedia)
- Level 0 - One URI one HTTP method - e.g. SOAP
- Level 1 - Many URIs, one HTTP method - e.g. most RESTful services that aren't (still loved, because people love URIs)
- Level 2 - Many URIs, each with multiple HTTP methods - e.g. Amazon S3
- Level 3 - Resources describe their own capabilities and interconnections - e.g. AtomPub
- The Web allows decomposition of complexity via many URIs, HTTP splits complexity by partitioning read operations (GET) and the write operations (all the others). Composing these yields sophisticated systems
- GET matters because it is constrained, and so you can optimise (level 1 services ignore these constraints)
- HTML only knows about GET and POST - tension between more specific constraints and opportunity to optimise, versus clients not understanding the enlarged vocabulary
- PATCH used in launchpad Web service, for partial updates
- Beyond a certain point to use POST and describe the differences with hypermedia
- Amazon S3 interface is the Web equivalent of a scavenger hunt, and creates coupling between client and server because of out of band rules for client-size generation of URIs
- Question: Can the Amazon scheme be seen as a relevant URI? Answer: No, because you have to URL escape it
- Question: Is there a way to specify what the root is within the Amazon document? Answer: Yes
- Netflix has a custom XML vocabulary, but hypermedia controls are there
- In launchpad, server-side fixes don't affect clients
- Links are one kind of hypermedia, forms are the other kind telling you how to manipulate resources - the form gives the POST operation its semantics
- Prefer hypermedia to media - just read in the hypermedia and play by normal rules
- Question: How do you distinguish between which HTTP methods are valid? Answer: Form action, or OPTIONS
- Lots of Form technologies, expect convergence - all just describe what HTTP requests you might make
- Limit to complexity that you can automate - divide and conquer spreads complexity around, refactor to reduce complexity, make complexity learnable through standardisation: divide and conquer: URIs, refactor: HTTP, standardise: hypermedia