These are my unedited notes from Steve Vinoski's talk at QCon London 2008.

• Steve talks about Serendipity -- I never knew about http://en.wikipedia.org/wiki/The_Three_Princes_of_Serendip
• How did a CORBA guy get involved with REST? At IONA, Steve was the IT Engineering department
• Built lots of tools, integration w/ Wikis, IRC, ...
• Tried to convince IONA to change course towards those things
• Failed and switched companies as a result
• Has no agenda, does not want to sell anything -- now involved with other stuff
• "The definition of a legacy application is 'one that works'" -- QoTD!
• Descendants of RPC: CORBA, EJB, .NET, SCA, SOAP, WSDL
• Message Queueing and EAI as alternatives
• Problems with MQ: Generally proprietary, except for JMS and AMQP
• 18 months ago, Steve was working on Qpid (Apache AMQP implementation)
• EAI products typically centralized hubs, proprietary and expensive, costly
• Some ESBs fall into this category (mostly re-labeled EAI products)
• Problems with RPC Approaches
• Focus on language first
  • tries to fit the distributed system to the language, not vice versa
  • making distributed calls appear local
  • expose language-specific objects directly as language-independent services
• Code generation (whether from WSDL or from code) creates deceptively significant consumer-service coupling
• Java-to-IDL mapping created horrendously complex IDLs, translated very poorly for other languages
• Type system illusions -- no type safety across the wire, type specialization is costly for scalability and reuse
• Interfaces are protocols -- specific interfaces mean specific protocols
• Data specialization: XML is better than IDL or native language types (because of reduced dependency via XPath)
• Unless you generate code from it, which makes the benefits disappear
• Integration problem summary: proprietary approaches too expensive, standard approaches focus on implementation languages, not distributed systems issues, new interfaces -> new application protocols (something he never notics ), ad hoc data formats coupled to interfaces -- all of this inhibit reuse
• Detour: Unix Reuse
• A tool like awk, written ages ago, can still be combined into brand new tools via a pipe
• Unix uniform interface: file-like object
• stdin/stdout/stderr
• standard ways to get data from/to applications
• A question to consider -- was the pipe invented on day 1? Or discovered later -- serendipity?
• Refresher on HTTP's uniform interface
• Explains idempotency of GET, PUT, DELETE; lack of idempotency of POST
• XML-RPC and SOAP/HTTP use just one -- and it's the worth
• Uniform interface enables visibility into interactions
• enabling caching, monitoring, mediation ...
• strong implementation hiding
• simplified overall architecture
• Original name of REST: "HTTP Object Model"
• Most of the stuff Steve's done in the past -- building ORBs and such -- dealt with the effects of having a specific interface (generating code, creating the runtime infrastructure). Most of this stuff disappears in REST
• with distributed objects, there's usually a lower layer that's generic, with generated code on top
• no generated code necessary
• curl more useful than a browser
• Server-side dispatching becomes easier
• Explanation of susconstraints (resource identification, representation exchange, self-describing messages, HATEOAS)
• Representation format not resource-specific
• Many different formats -- even XML if one's sad and desperate
• Media types registered with IANA
• Makes datatypes an orthogonal concern
• Recommendation: Beautiful Soup library for Python if you ever need to do screen scraping
• Hypermedia constraint -- resources provide URIs that guide the client
• RPC systems conflate methods and data, while REST separates methods and data formats
• In REST, fixed set of methods, many standardized data formats
• Question: Why would REST separate data and methods better than other approaches?
• Answer: REST encourages this, other approaches encourage the opposite
• Things like caching are generically possible
• Praise for the REST dissertation - "the clearest architecture document he's read"
• Enhancing reuse possibilities - separate libraries and tools helping with data and methods
• Libraries for interception and mediation, caching
• Example: bug tracking system with HTML, XML, XCS, JSON data
• Even while working for a company that built RPC tools, he was using lightweight, Web approaches to do internal stuff
• Independence -- each of the resources in the example system could be added independently without disturbing existing resources and formats
• Plant the seeds to see what grows
• Summary: RPC-oriented systems try to extend language paradigms over the wire -- encourages variation (in methods, datatypes), which can't scale
• REST is purpose-built for distributed systems, properly separates concerns and allows constrained variability only where required
• "Roy Fielding: Engineer for Serendipity" -- which, according to Steve, is possible
• Question: Are data grids instances of REST because they have a uniform interface?
• Answer: only possible by looking at all constraints, not just the uniform interface -- maybe, unknown: idempotency, restricted variation in data formats
• Comment by Joe Armstrong: How about adding data immutability -- outlaw PUT and POST, instead add APPEND
• Answer (both Steve and I): POST really is APPEND; you could just outlaw PUT