This continues a series of columns from practitioners I respect. The category "Real Deal" describes them well.
This time it is Mark Herring, SVP of Product Marketing at Software AG. I recently heard him talk about "Big Services" as a unheralded cousin of Big Data and invited him to write about the changing world of services and APIs, which his webMethods product gives him a nice perch to observe from.
“In my role I meet with many customers and have the unique privilege of seeing the hype cycle through the eyes of my collective customers. Many customers are moving aggressively in exposing their systems as API’s as they try to address the huge demand for mobile access to their systems. One misconception that I have to often address is the perception that there are so many API’s already out there that by combining a few API’s together they should be able to get their systems out even quicker.
The Programmable Web lists almost 9,000 APIs that are publicly accessible, which should be a boon to productivity. Basically the theory sounds fabulous – create new applications by combining an API from vendor A, with another API from vendor B, with a bit of business logic from my business. Unfortunately the truth is that most reusable API’s are not being reused. There are a few reasons for this lack of reuse:
Many of the API’s that are out there are in the category of “No one cares!”. Well maybe someone cares, but by in large do we need another photo sharing service, a daily fact API or a classified service API. I would put this list at about 50% of all the API’s out there!
The next category “Interesting but no SLA” accounts for another 35%. There are a plenty of interesting API’s that I might want to use but either the company providing them is unknown, or the API has no service level agreement. There is no way that I would want to put this API in my application or mashup since it going down would mean problems for me. No one want to deal with the error “Sorry service unavailable”.
The next category is what I call “Great.. BUT”. These APIs seem usable, they provide a service I need, they meet my requirements for availability, BUT if only they had this extra return value, or this one extra feature. There are by far the most frustrating API’s to deal with. The most common way around these is just rewrite them to give the exact results I was hoping for. This probably accounts for an additional 10% of the publicly accessible API’s.
The final list is “Widely used”. This is by far the smallest subset, I attribute 5% of all APIs in this category, but even then I think I am being a little too generous. The list includes APIs such as FedEx/UPS tracking, Google Maps and potentially Credit Check. The limitations with these API’s is that often an account is needed because the API provider is assuming risk/liability. For instance the Credit Check API will be provided by one of the credit bureaus or card processing services and if the check passes and funds are credited they may assume the liability if at a later stage the transaction was deemed to be from a stolen card.
What Does This Mean For YOU?
Review publicly assessible API’s, but don’t be disheartened that many of them will not fit your needs. API reuse is only one benefit; arguably the biggest benefit of API’s is mobile access to business systems. When building your own API think of public usage and reuse, since these are good design patterns to emulate. And finally, adopt a robust and secure API management strategy."
Mark can be reached at mark DOT herring AT softwareag DOT com
