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
