In July, I had the opportunity to present at the Austin Java User Group monthly meeting about the design and architectural evolution of Apigee Mobile App Performance Monitoring service. Attendees were enterprise Java and Java EE developers so I focused mostly on how different Java and Java EE technologies such as JAX-RS, Drools, JPA, Hibernate, Seam, JSF and Richfaces can be integrated with some cloud services to build a distributed and highly available SaaS. Thanks Austin JUG for the opportunity and a great discussion.
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?
A frequent question from people who have an existing SDK is “Do I need an API?”
First, what do we mean by “SDK” and “API”?
An SDK, software development kit, is usually compiled code that is distributed to developers to embed on local devices.
An API, application programming interface, is a set of operations exposed for invocation by a remote system. (For the purposes of this discussion, we will keep the definition of an API at this high level and not delve into REST vs SOAP, good API design, etc.).
These days, SDKs are generally used when specialized processing...
In our last couple API strategy workshops, we've had good discussions on a common question for API providers - do you need to offer an SDK (software dev kit) for your API?
In this context we defined an SDK as going beyond offering an API to include platform-specific code that developers use in their apps to invoke API operations, also including the source code, and documentation that developers might need. Here's what we came up with:
Reasons to consider an SDK:
Speed adoption on a specific platform - for example Objective C SDK for iPhone. Lots of...