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: Dan Diephouse -- "Building your next service with the Atom Publishing Protocol"

Stefan Tilkov,

These are my unedited notes on Dan Diephouse’s talk “Building your next service with the Atom Publishing Protocol”.

  • Atom history (created out of frustration with existing formats and protocols)
  • Introduction to the Atom feed structure
  • Relation of Atom feed into the AtomPub model
  • Collections are just Atom feeds - two types of entries: Entry, Media Link Entry
  • Services and Workspaces - workspace contains collections, collections contain entries
  • Glen Daniels asks why collections don’t simply contain collections
  • There is no way to work with the Workspace through the protocol (unfortunately)
  • Sanjiva: doesn’t the service document introduce coupling to the content types accepted? Dan: you can keep it general, or accept more. Again:
  • Dan believes the service document is very close to a full service description, but there’s still no way to link a MIME type to a schema
  • Atom specifies how to edit, delete, create, resources in collection
  • extensible protocol
  • properly uses HTTP
  • sample set of resources: GET /, retrieve service document, GET first resource, get feed
  • Entries contain a set of links - you can define your own via rel attribute
  • POST an entry to collection, including a client-generated unique ID - result: Location and entry document (server creates resource, creating the URI)
  • GET will return entry, including ID (which my or may not be the same as the one supplied by the client) - server uses the client ID to ensure reliable POSTing
  • Some discussion whether the client-supplied ID is a bad or not - agreement that if it’s a unique ID, everything is fine
  • PUT will update the entry
  • ETag headers specified in the protocol
  • Atom supports non-XML and arbitrarily large data by putting them into media link entries
  • more explanation of this showing a picture collection
  • POSTing a picture, including a slug for the title - server returns an entry including the picture metadata and a link to the actual binary data
  • Atom defines the rel values
  • Question: there is no way to specify binary and metadata in a single request. Answer: no.
  • Multipart is perfectly feasible (as a private extension to the protocol)
  • why use Atom?
  • Atom is widely understood, adds ubiquitous elements which have meaning across all contexts - summary, content, updated date, ID, links
  • clients do not need to understand app-specifics to interact with the service
  • AtomPub guarantees that you’ll follow RESTful best practices
  • avoid writing your own protocol
  • many frameworks are popping up
  • building services patterns and strategies
  • Frank Zappa quote on stupidity ;-) including reference to Sanjiva’s talk
  • (tuned out here for a few seconds to order an iPhone, sorry)
  • Dan terms Open Search description “the WSDL for search”
  • offers a way to tell people how to search your service
  • Opensearch defines a “rel” link
  • some quick notes about GData: “simple standard protocol for reading and writing data”
  • not that simple from Dan’s point of view
  • standard way to query feeds, defines optimistic concurrency model, way to authenticate users, common elements for Google services, batch operations; all built on AtomPub
  • at least one Google-independent implementation of GData (in Abdera)
  • APP doesn’t do batch - GData does, but hasn’t received warm reception
  • feed with “operation”-specific operations in the feed
  • while there’ve been many complaints, there hasn’t been an alternative suggestion
  • some discussion about the right batch model - suggestions from Stu: either pick a super-resouce and update that, or use a single connection and pipe through it
  • Mike Herrick points to James Snell’s suggestion to use multi-part
  • Stu: reasons against pipelining include broken intermediaries
  • Suggestion from Patrick Logan: nothing wrong with submitting many things at once and retrieve results in a feed
  • Thoughts on GData: does it expose a weakness (AtomPub is not enough) or a strength (can be extended)? Dan thinks the latter
  • Hierarchies not easily modelled
  • Standard suggestion: put a link to the collection into an entry (in a collection element) - possibly adding rel attributes if there’s more than one collection
  • Client needs to know the collection element is there, not a required part of Atom
  • Question: Any experience using RDFa for collections? Answer: no - RDF scares him :-)
  • Eventing: usable with any Atom client - for business events, exceptions, fault monitoring … powerful combination with OpenSearch
  • Security: first, be sure you know your goals - SSL, HTTP Auth, WSSE, Google Auth, XML Sig and Enc
  • Individual Atom elements can be signed and encrypted; enables use cases where a collection contains items signed or encrypted by different parties
  • When not to use AtomPub: when data is not time-indexed, universality doesn’t yield any benefits, batch, performance, messaging may be a more appropriate model, hierarchy kinda sucks, transactions
  • Next up: a possibly pointless comparison to WS-*
  • scalability similar; feature applicability: WS-* provides message ordering, security, trust; but also WSDL, complexity, interoperability problems
  • WS-* easier for developers than AtomPub
  • Is AtomPub the one true protocol? no, but it can be applied in a wide variety of business apps
  • universality, hypertext model is powerful, AtomPub is a great example of a RESTful application