QCon SF: Dan Diephouse -- "Building your next service with the Atom Publishing Protocol"
November 9, 2007
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
About
This page contains a single entry from Stefan Tilkov's Random Stuff posted on November 9, 2007 2:03 AM. The previous post in this blog was QCon SF: Pete Lacey -- "Demonstrating the 'ilities' of REST". The next post in this blog is QCon SF: Obie Fernandez -- "Desiging RESTful Rails applications". Many more can be found on the main index page or by looking through the archives.