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 London 2008: Steve Vinoski on Serendipity and REST

Stefan Tilkov,

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
On April 20, 2008 3:12 AM, sohbet said:

thanked post