I've talked about versioning as one of the most important considerations when designing your pragmatic RESTful API. So it deserves another mention, keeping in mind basic versioning recommendations, such as:
- How many versions should you maintain?
- For how long should you maintain a version?
In the last post in this series about Pragmatic REST API design, I talked about designing error conditions in your APIs. This time - versioning - one of the most important considerations when designing your pragmatic API.
We're starting to get some great questions from signups for next week's API design webinar: "Pragmatic REST - API Design Fu".
Here's one we'll comment on now and then talk about more next week.
Q: "For API Versioning. Doesn't seem very RESTful to version a resource. Can it be avoided by using implementation and specification versions described in the Sun API Cloud Documentation?"
A: Your question is an insightful one. Versioning is an open issue for REST API design in practice.
Clearly, an API will need to change it's behavior over time. As it changes application developers will need...
We've seen an architectural pattern emerge over the last two years that deals with the expanding variety of computing devices and the exploding number of APIs used in modern applications. This pattern is API Virtualization - applying a virtual layer above the API itself to deal with the different concerns that come into play when delivering an API to different device and machine endpoints as well as across a range of different classes of business relationships.
Sam Ramji gave this presentation at GlueCon as a Prezi. The...
Daniel Jacobson of NPR posted a fascinating piece about how NPR tackles a common problem – what’s the best way to render content on a variety of devices, from modern web browsers with top-notch CSS implementations that look almost like typesetting (like Safari) to mobile phones using WAP to low-end devices like HD Radio receivers that don’t understand anything but plain ASCII text.
NPR’s clever solution is to strip markup out of the text and store it in a database table, indexed by position in the text document. To re-generate the content for a particular device, their software queries...
(continuing our series on API roadmap considerations)
TrueCredit.com tells a story of calculating they would need thousands of IP addresses for all the different versions and flavors of their open API - to account for different variations and versions needed by partners.
Even if you have a ‘one sized fits all’ API - you might need to be able to transform data, mediate terms or customize SLAs without coding each change or a creating a new version of the API. Reasons could include:
• Protocol needs - A SaaS customer with a...
Scott Metzger, CTO of TrueCredit.com was kind enough to take some time to talk about their Consumer Connect API program and some of the technical challenges that they have addressed using Apigee's API Gateway.