The article's "pros and cons" paragraph is particularly interesting, and the section about the importance of 'abstracting' the API from how the underlying service really works was important to me when designing the Tesco.com Grocery API.
Our underlying grocery service is a complex system with many components, and if I enabled it fully through the API:
- It might be easier to recreate without our permission (the grocery service is part of Tesco.com's intellectual property).
- It would be more difficult to use - or rather, easier to use incorrectly.
- It might be easier to attack through uncovering any unknown flaws in the system due to its complexity.
That's why our design distilled the entire grocery service into just 10 basic commands - a complete abstraction from the real service over which it sits:
- List product categories
- List products in a given category
- Search for products by text search / barcode
- List Basket
- Change Basket (a single command for adding / deleting / changing quantity)
- List Delivery Slots
- Select a delivery slot
- List pending orders
- Amend Order
These commands are easy to understand, obvious to use (I hope) and protect the underlying service from attack through misuse.
The Revolution article then concludes with a salient point:
Opening up a site's API is not simply a cheap option for brands to get free coding; there are costs involved in monitoring use, refreshing the technology and supporting developers. It is also a dud option for brands that are unexciting to developers.
We better make sure Tesco.com stays exciting then...!