Continuing on from Fred's talk on owl vs deer, Jonathan gave a talk on the differences between the current Atlas 3.0 API and the upcoming version 4.0 on July 17th, 2013.
Covered the history of Atlas (née URIplay) and what it does • Explained how the new Atlas deer release differs from what came before • Tom • Had just given us stable content IDs • This will be important later
type URIs represent a collection of all resources of that type • Resource type URIs support querying of resources of that type • Every resource has a single canonical URI under its resource type • Support the common use cases in simple, obvious ways • Ensure a guaranteed, consistent speed of response for more complex queries
wasn’t RESTful - it was • Atlas and URIplay have always been very of the web • URIs as IDs make it hard to support things like POSTs, or PUTs to subresources • They’re also hard to pass round in URLs and for other people to use • So the URI of URIplay is now gone • All resources in Atlas now have an Atlas-generated web-safe ID
URI • /4.0/content.json?aliases.namespace=uri&aliases.value=http://www.bbc.co.uk/ programmes/b006q2x0 • Aliases provide a powerful new mechanism • /4.0/content.json?aliases.namespace=gb:bbc:pid&aliases.value=b006q2x0
different resource types in a response • This is done using a dotted syntax • /4.0/schedules/hkqs.json?source=bbc.co.uk&from=2013-07-17&to=2013-07-18 &annotations=content.description,content.topics,channel.detail
querying at scale • Filters will be built out as use cases are proven • Our general rule: • The URL that represents the collection of all resources of the type you are looking for is used to query for resources of that type • /4.0/channels.json?title=Film4
not everything • Realtime equivalence processing • More granular equivalence merging • Self-service data requests and key configuration • Change history