In earlier eras of software development, programmers quite often had the luxury of using a stable version of a platform or API, because even when vendors updated their apps, OS’s, and middleware, the organizations relying on those platforms could implement those upgrades in their own time. But now with online web services, developers often have less control over updates to the API they are using, and unannounced changes to web service APIs are becoming a big problem, as Gartner’s Benoit Lheureux reports:

This week in Las Vegas at Gartner’s SOA / ADI Event I hosted a Analyst / User Roundtable on the topic of Cloud computing / SaaS integration. One attendee which has already (impressively) leveraged the services of a dozen SaaS vendors claims that four of the twelve  providers have changed API’s without notification, impacting production operations. A few other members of the group cited some experience with what I’ll coin here (strictly for the entertainment value, of course) “API slamming”.

Rick Nucci also noted the issue in his post The Top 10 Most Common API Pitfalls, with inadequate API versioning making it in at number 3:

3. Developing a single version of your API which changes with each release of your SaaS application

Impact: Your customers get on the “API treadmill” which requires that they repeatedly have to test their integrations with each release of your application. This will inevitably lead to push back from the customer base which may result in pressure to reduce the frequency of your product releases.

There are some simple solutions. Alex King shows how to implement versioning with a simple modification to the API endpoint:

When people build to your APIs, they need to continue working – even if/when the APIs need to evolve over time. The best way to do this is to build API versioning right into the API URLs themselves.

Yes: api.example.com/1.0/command
No: api.example.com/command

Rick Nucci says providers should:

Think of your API as a contract between you and your customer. Once you release it, that specific version needs a SLA guaranteeing compatibility to it for some extensive period of time (years). As you release new versions of your application, version your API also.

You can find more on REST API versioning in an earlier series of blog posts from Peter Williams and this one from Dare Obasanjo. For a more SOAP-centric perspective on this, InfoQ has this handy book excerpt on Web Service Contract Versioning.

API Slamming, API Treadmill… Whatever you call it, the lack of a stable API is a major headache for developers, and with thousands of APIs to choose from, it is a quick way for vendors to lose customers to competing services.


Go to Source

No related posts.

Leave a Reply

 
Special Offers
Blogroll

Pages
Tags