So far in the API design series, I've looked at best practices for designing pragmatic RESTful APIs.
This time, I'll talk about complementing APIs with code libraries and SDKs.
What to do when building a UI requires a lot of domain knowledge?
This image is an example of a twitter app displayed in a newsroom.
A developer created this cool visualization - a tweet referencing another twitter user.
The Twitter API is one of the simplest app domains imaginable: the primary object is 140 characters of text. Yet, the developer who created this needed quite a bit of domain knowledge - they needed to parse the tweet, color code it, and display it in a certain way.
The API team shouldn't try to solve presentation problems with the API. That's what code libraries do. Instead
Complement your API with code libraries and a software development kit (SDK)
That is, don't overburden your API design. A lot of what's needed in scenarios like this is on the client side and you can push that burden to an SDK.
The SDK can provide the platform-specific code that developers use in their apps to invoke API operations - meaning you keep your API clean.
Other reasons you might consider complementing your API with an SDK
- Speed adoption on a specific platform - for example Objective C SDK for iPhone. Lots of experienced developers are just starting off with objective C+ so an SDK might be helpful.
- Simplify integration effort required to work with your API - If key use cases are complex or need to be complemented by standard on-client processing.
- An SDK can help reduce bad or inefficient code that might slow down service for everyone.
- As a developer resource - Good SDKs are a forcing function to create good source code examples and documentation. Both Yahoo! and Paypal have good examples.
- To market your API to a specific community - you upload the SDK to a samples or plug-in page on the platform's existing developer community.
Next time: API Virtualization