Enterprise APIs and Public APIs
by
Join the DZone community and get the full member experience.
Join For FreeOver at APIEvangelist.com, Kin Lane has a great list of "Successful APIs to look at when planning your API".
These include Ebay and Flickr. It's a great list, showing how APIs can
be very different from each other. Some are OData-y (Ebay), some still
support SOAP as well as REST (e.g. Amazon), and some are closer to REST
Nirvana than others [if you want to make a RESTafarian's head explode,
show them Flickr's delete operation which uses a POST.].
But one thing all these APIs have in common is that information about them is publicly available, to anyone, and anyone with the right credentials can use them. APIs which are used inside organizations, or within groups of trading partners, are not mentioned. At the Cloud Identity Summit last month, Romin Irani from Cisco called these "Dark API's". The analogy is with Dark Matter. It's all around us, but we can't see it. Organizations are using enterprise APIs, which the outside world may not know about. Same goes for APIs used within products. I've written before, back in 2009, about why there isn't a Pandora API. Fast forward to 2012 and Pandora still doesn't have a public API. It doesn't fit their business model to have one [something that's worth a whole blog post in its own right]. But you can bet Pandora has their own API definitions they use internally. Effectively, that's a "dark API" too, even though it's for an entertainment service. So the distinction is not about "Enterprise versus Consumer" anymore (echoes of Eve Maler's excellent OAuth 2 piece)
For many of Vordel's API Server customers in the healthcare and financial transactions sectors, it doesn't make sense to have a "Public API". But they still want to leverage the benefits of APIs (e.g. for a HMO to talk to its hospitals). Eric Knipp from Gartner has been doing some really good research on this, about the distinction between "Public APIs" and "Enterprise APIs". Whatever terms we end up using ("Dark APIs", "Enterprise APIs"), it's definitely a conversation worth exploring.
But one thing all these APIs have in common is that information about them is publicly available, to anyone, and anyone with the right credentials can use them. APIs which are used inside organizations, or within groups of trading partners, are not mentioned. At the Cloud Identity Summit last month, Romin Irani from Cisco called these "Dark API's". The analogy is with Dark Matter. It's all around us, but we can't see it. Organizations are using enterprise APIs, which the outside world may not know about. Same goes for APIs used within products. I've written before, back in 2009, about why there isn't a Pandora API. Fast forward to 2012 and Pandora still doesn't have a public API. It doesn't fit their business model to have one [something that's worth a whole blog post in its own right]. But you can bet Pandora has their own API definitions they use internally. Effectively, that's a "dark API" too, even though it's for an entertainment service. So the distinction is not about "Enterprise versus Consumer" anymore (echoes of Eve Maler's excellent OAuth 2 piece)
For many of Vordel's API Server customers in the healthcare and financial transactions sectors, it doesn't make sense to have a "Public API". But they still want to leverage the benefits of APIs (e.g. for a HMO to talk to its hospitals). Eric Knipp from Gartner has been doing some really good research on this, about the distinction between "Public APIs" and "Enterprise APIs". Whatever terms we end up using ("Dark APIs", "Enterprise APIs"), it's definitely a conversation worth exploring.
API
IT
Business model
REST
Web Protocols
Leverage (statistics)
Nirvana (software)
Eric (software)
Conversations (software)
Published at DZone with permission of Mark O'Neill, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments