we write about the things we build and the things we consume
Very soon we’ll be giving everyone early access to the new 4.0 schedule API in Atlas Deer. This will be the first public alpha release of the new schedule and you can expect many things to change and break while we finalise things over the next few months.
I just wanted to give everyone a quick run through of what you can expect and what’s still to come. More importantly this is a chance for everyone to provide feedback before we make the first version available, so that we concentrate our efforts on the right areas.
what you can expect
- The initial release will be an alpha that can and will change
- Complete schedules for BBC and PA (PA will still require a key)
- We’ve made changes to the urls and request parameters
- We’ve made some changes to the schedule resource representation
- We’ve not yet made major changes to the content resource representations
- It should be faster, but more importantly it should perform more consistently
what the api will look like
A schedule request for a single channel now gets its own resource, based on the channel id. A basic request looks like:
We now also support content negotiation as an alternative to specifying a format extension. We’re not serving a default format, since we want to make it clear an Accept header is required, but that means you can also do:
Accept: application/json GET /4.0/schedules/cbbh?source=bbc.co.uk&from=2012-10-25&to=2012-10-26
And the end result is the same.
We don’t yet support multiple channels in a single call in the new API, though it is likely we’ll add this as a request to /schedules:
publishers are now sources
As you might have noticed from the requests above, we’ve taken the opportunity to rename publisher to source. These represent the different providers of data within Atlas and we feel that as Atlas grows source is much more appropriate and less confusing name.
what’s not yet changed
While the schedule itself has seen some minor cleanup, we’ve not yet made an major changes to the representation of content items. We expect that these will change, not least because we’re trying to move to a model where everything we know about a resource can be read and written from the API, but it’s going to take a bit of time yet to fully shake these out. While the API is in alpha, please be aware that we may make a breaking change at any time though we will try to give at least some warning.
Please do let us know what you think of these changes. As well as the new API structure, I’m particularly interested in any comments on how we should change the content representations to make make them easier to work with. Please leave a comment with your thoughts or let us know in the discussion group.