In May this year, a group of us (parents, friends and teachers) from my sons' school are cycling from Nottingham to Paris in order to raise money for the school. My role in this exercise, in addition to cycling, is to build and manage a website (www.r4rh.org) to promote the event.
Part of that web site includes retrieving a set of latest photos from Flickr tagged r4rh or RideForRoundHill. I've built the site using ASP.NET so naturally downloaded the Flickr .Net API Kit. My needs were very simple, just searching for a list of photos, and it worked brillantly until I published the site.
For some reason, I don't know why, the reference to the FlickrNet.dll didn't see, to carry across. Initial investigations didn't uncover a solution, one of the problems I find with doing this kind of thing these days is that my integration problem solving skills have got very rusty, so I browsed deeper into the Flickr APIs.
I've been reading RESTful Web Services by Leonard Richardson and Sam Ruby recently and the ethos of REST style web services has been intriging me greatly so I decided to have a go at consuming the Flickr REST API.
Boy it was easy.
- Do GET from URL with API key and search parameters
- Receive XML document
- Parse XML document to get list of photos
- Build list of images to render on web page.
Now if you end up reading Leonard and Sam's book you'll discover that in their view, Flickr's REST API is not truly REST but actually a REST/RPC hybrid. He does go to great length to make the case for pure REST services but in my view, from a usability point of view, this ticked all of my boxes.
- Simple to make the API call: just construct a URI
- Simple to interpret the results: wide support among development platforms for XML parsing
- Loosely coupled: Flickr can add new data to the output without breaking my code
It's the above criteria that have been used to design the new Esendex API that will be coming to the Internet very soon. We are going REST.
The first release will be available in March to support an exciting new service we are bringing to market. This will be a sub 1.0 version, beta subset of the full API which we will augment to support the full feature set over the coming months.
We will of course formally announce the release on the Esendex Developer web site, and we will be maintaining support for our existing API.
Committing to this approach has also opened up some fascinating possibilities for our applications as well how we can build composite applications that combine all sorts of other services with our own. It's going to be a very RESTful year.