Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Zakia Bouachraoui, Elizabeth White

Related Topics: @DevOpsSummit, Microservices Expo, @CloudExpo, Apache

@DevOpsSummit: Blog Feed Post

API Axes - Categorizing APIs By @Axway | @DevOpsSummit [#DevOps]

This week there has been a great discussion between David Berlind of ProgrammableWeb and Kin Lane of APIEvangelist.com

This week there has been a great discussion between David Berlind of ProgrammableWeb and Kin Lane of APIEvangelist.com, on the topic of categorizing Public and Private APIs. David quotes my ProgrammableWeb piece on Uber and ESPN, which talks about different API strategies, public and private. He makes some great points on the fact that many APIs are not fully public. I thought I'd expand on it here:

I believe there are two axes which can be considered:

First of all, let's look at API Exposure. The two categories are:
  • External : Able to be used outside the organization.
  • Internal : Used only inside the organization
Secondly, let's look at API Management. It may be one of three categories:
  • Open: Anybody can use the API, anonymously with no controls
  • Requires Registration: Has a public registration page ("API Developer Portal"), where developers can sign up for an API Key. Developers are identified with API Keys and usage is monitored accordingly.
  • "Dark" APIs: I first heard this term used by Anand Shamra from Cisco. I like the analogy with Dark Matter, which is all around us, but we don't see it. These are APIs without a public registration page. As an example, there is no public Pandora API, but hardware manufacturers such as Roku still can connect to Pandora via an API.
These axes are orthogonal. Using these axes, APIs divide into six categories. I've put them into a table below:


External
Internal
Open No registration required. Usually they take the form of read-only public data feeds. An example is the Nobel Prize API, which allows a developer to query information about Nobel Prize winners. Another example is the Massachusetts Roadway Events API. Open to all internal access, for example a Company Directory API. Note that API Management (specifically, an API Gateway/proxy) may still be used to monitor usage and protect against abuse such as data-harvesting.
Requires Registration Requires the developer to register, and may have an approval process before they gain access, e.g. the CVS Caremark API. Anyone can read the documentation, but developers have to register to use the API. These APIs may have a DaaS (Data as a Service) approach, like the Dun and Bradstreet D&B Direct API. Internal corporate API Developer Portals. Many large organizations use internal API Developer Portals to manage API usage across teams, which often include partners such as Systems Integrators. The general public cannot access the developer portal.
"Dark" No public developer page, and based on a business relationship. Often these take the form of B2B APIs between companies. An example is a 401.K provider which uses APIs to receive allocation amounts from its corporate clients, through an API Gateway. Inter-government APIs for sensitive intelligence data sharing also fit into this category. Developer access may be "by invitation only". These APIs often are use SOAP or XML because they are not designed for open use. e.g. manufacturing system APIs or drug-trial lookup APIs used in pharmaceutical companies. These often still take the form of SOAP Web Services since they have not been designed to encourage widespread developer access.


This is a fruitful area of debate, so I've anticipated some of the questions below:

Q&A:

Q: "Why not say 'Private' APIs instead of 'Dark' APIs?"
A: I feel that 'Private' has too much potential confusion with "internal".

Q: "Does 'open' mean there are no security or API management requirements?"
A: Since I work for an API Management vendor (Axway), you can expect me to answer "of course not!" here :-). But, realistically, if  an API is fully open to the world, that is all the more reason to ensure that it's not subject to misuse such as data-harvesting, denial-of-service, or attempts at application-layer attacks. You should also keen track of how its being used, using API usage analytics. In particular, internal "open" APIs are precisely the APIs which can be subject to internal attacks, often by attackers who get onto the internal network by (for example) compromising weak WiFi security. Access to these APIs must still be monitored and logged. Consider the example of Sony Pictures which, by some accounts, was the subject of an insider attack.

Q: "Could you not say that an API with an external developer portal is still an 'Open' API, because anyone can (at least in theory) use it once they are approved?"
A: In many cases, the API which requires registration is linked to a business relationship. For example, in the case of the D&B  API which has a "Data as a Service" model (which you can read about more in this account of our API Workshop presentation by D&B recently), the API is an important new revenue channel and access is metered by an API Gateway. Here I'm using "Open" to mean that anyone can access the API without any kind of registration.

Q: "Could you say that some internal APIs are only 'Dark' just because nobody knows they exist?"
A: Yes, and these are the wrong kind of Dark APIs. Wired Magazine has noted that "It is insanely easy to hack medical equipment" because many have "embedded web services that allow devices to communicate with one another and feed digital data directly to patient medical records." These are examples of internal APIs which Randy Heffner from Forrester has called "Product APIs". Do you know if devices on your network have product APIs? Are they protected? Do you even know about them? Could an attacker, who can get onto your network, misuse them?

Q: "With 'Deperimeterization', can you not say that 'Everything is an External API'"?
A: This week I visited a customer, a large pharmaceutical, which explained they have a fully "flat" network. However, they still use API Gateways to control access. It's all the more reason to have an API Management layer in place.

This is a hot topic, and I anticipate more debate on it! I suggest everyone follow @DBerlind and @Kinlane on Twitter to take part.

Read the original blog entry...

More Stories By Mark O'Neill

Mark O'Neill is VP Innovation at Axway - API and Identity. Previously he was CTO and co-founder at Vordel, which was acquired by Axway. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.

@DevOpsSummit Stories
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
DXWorldEXPO LLC announced today that Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
This session will provide an introduction to Cloud driven quality and transformation and highlight the key features that comprise it. A perspective on the cloud transformation lifecycle, transformation levers, and transformation framework will be shared. At Cognizant, we have developed a transformation strategy to enable the migration of business critical workloads to cloud environments. The strategy encompasses a set of transformation levers across the cloud transformation lifecycle to enhance process quality, compliance with organizational policies and implementation of information security and data privacy best practices. These transformation levers cover core areas such as Cloud Assessment, Governance, Assurance, Security and Performance Management. The transformation framework presented during this session will guide corporate clients in the implementation of a successful cloud solu...
So the dumpster is on fire. Again. The site's down. Your boss's face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke. Yes, we know this is a developer's fault. There's plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone's job. But we're civilized now. Sort of. So we call them post-incident reviews. Fires are never going to stop. We're human. We miss bugs. Or we fat finger a command - deleting dozens of servers and bringing down S3 in US-EAST-1 for hours - effectively halting the internet. These things happen.