I'm writing a book for O'Reilly and I'd love you to comment on this outline, see earlier post for more information.
Let me know what is missing and what examples you'd like to suggest for the book. Comment below or send me an email me at gavinbell dot com or zzgavin on twitter.
- On the internet vs part of the internet
- Amazon and google vs most publishers
- New York Times and The Guardian
- Seeing the wider internet
- Integrating with the wider internet
- Building an API
- Why make an API?
- People and objects, the stuff of social applications
- Collections, tags, places and time as containers for objects via API calls
- Services not sites, programmatic access to data, not page generation
- Interoperability and Snowflake APIs (your data is not that unique)
- API traffic volume to twitter / flickr
- Supporting activities, not implementing features
- Using your own public API to make your stuff
- Microformats and RSS (read only apis)
- Where appropriate, bulk usage better via api, so that data only can be sent, not images and css along for the ride
- HTML badges
- Your data on someone else’s site, simple and easy to use
- Writable APIs
- Authentication required
- Security and OAuth
- Latency
- Examples Flickr / Twitter / MovableType and blog apis
- Sticking with standards
- Identica and other apps mimicing the twitter API
- RSS, Atom and AtomPub
- API scaling issues
- XMPP
- queues
- Real time vs near realtime
- NY TIMES, Flickr panda bears
- Privacy and security around APIs, commercial aspects
- Developer community management (wikis, mailing lists etc)
- Integrating existing or competing projects (whatever the route)
- Multiapp integration
- Registration SSO - OpenID and OAuth
- User management
- Data migration headaches and how to avoid them
- Having one of everything, not duplicates
- Email notifications - managing your output from multiple applications
- Internal integration (message queuing)
- On the cheap polling RSS
- Database calls, fast and brittle
- Queues and message passing
- Dealing with multiple claims of authority
- Family of identifiers better than one?
- Search
- Single search databases (big solutions like MarkLogic)
- Cooperative approaches (polling multiple databases and integrating)
- Multiple content sources with a single search interface is a hard problem, common for many publishers
- Community and published content, blog vs publishing workflow tools, who wrote this?
- Integration with other people’s APIs
- Functionality for free from others FTW
- How to manage external dependancies on others APIs
- Understanding provider and consumer relationships for your application
Generally looks like a sane outline. My first thought was that XMPP is more about realtime than scaling.
I also think that the Flickr "extras" pattern is really useful as a way of avoiding API joins, and I'm not sure where it should be mentioned, but it does need to go in there somewhere.
Hi Gavin
I have a lot to say on some aspects of this page. But it wont fit in a tweet, or easily in a comment, so if you're interested to hear let's have a skype.
Terry
Thanks blech
The Flickr extras pattern, I'll add in as this is as much about using apis, as it is about designing APIs.
Terry, I'll drop you an email.