Magnificent Seven for APIs

Some interesting survey results have just been published about APIs: the good, the bad and the pains. I commented about this on G+ and the discussion there got on to Atom. Some interesting points made, including the likelihood that we're stuck with snowflake APIs (every one is different) for the foreseeable future. I think it was Bill de hÓra who had a post years ago (can't find it now) about the N x N problem of diverse APIs (/models/formats). Essentially if you've got N different APIs then to connect them all you need N x N different translators. But it's also worth noting that this can be reduced to 2 x N if you have mappings to a common format/model. I reckon recent history has shown that formats are secondary, assuming certain boxes are ticked (see below). Regarding the model - there is a well-known, Web-friendly one. So here I'll simply point to ConverterToRDF and ConverterFromRDF.

In the G+ discussion Bill referred to an old blog post of his, Magnificent Seven - the value of Atom. In it he highlights the 7 'primitives' that Atom (format and protocol) uses and that he suggests should be used in any carrier format. I'm inclined to agree, if you are creating an API, tick these boxes, repeated here without Atom-specificity:

  1. ID - a globally unique identifier for the chunk of data, ideally this should be a HTTP URL
  2. Link - as above, it's rare that a separate ID and URL are needed
  3. Updated - the most recent change, invaluable for keeping things in sync
  4. Extension rules (mustIgnore, foreign markup) - anything the parser doesn't understand, it simply ignores. This allows other people to reuse and extend the format in a compatible fashion.
  5. Date construct rules - using a standard date format is basic politeness
  6. Content encoding rules - generally follow the rules for the media type you're using, and if there's textual content use an existing standard format (XHTML is good). Rule of thumb: UTF-8.
  7. Unordered elements - insisting on order in the structure is (or at least should be) unnecessary, accessing things by name is more reliable
The most significant bit is the ID/Link, this is essential for any API on the Web. It allows the use of the "follow your nose" protocol: if you want any more information about a thing, follow the link. It works for regular Web documents and increasingly for linked data.
Incidentally (1), if you are an API developer/user you may like to have a look at the Linked Data API, looking at what's needed to make access to data in a SPARQL-capable store more developer-friendly. Comments welcome there.
Incidentally (2), Google Plus is emerging as a pretty good discussion space, if you're in need of an invite mail me.


danja
2011-08-13T09:42:21+01:00
apis atom federated json rdf
Related
Comments
Edit