API Strategy Series: Expanding the Potential User Base

This article focuses on a strategy for maximizing the potential user base by reducing the barrier to entry and the complexity of API integration.  If more users can derive value from a service, then the more valuable the service. 

Where is Opportunity

The user base for APIs are naturally limited because of the cost of integration. API integration is costly for a three reasons.

1. Specialized skills are required to create the integration

2. Specialized skills are required to support and maintain the integration

3. Creating the Integration is Complex and Costly

Typically the client bears the burden of integration development cost. In some cases the providers takes on the burden of development cost and provides out-the-box integrations. In either case, typically software developers create the integration. You then usually have a mixture of operator and programmer (devops) to support and maintain the integration. This leads to costly solutions because the skills above are highly specialized.  

The integrations created are often complex. This can often lead to issues with support and maintenance.

The Importance of Simpler Integrations

Pulling in any behavior that may normally live in the integration, into the control point eliminates the additional code and complexity for that behavior from the integration.

Pulling in all the behavior in the integration, except for the core business logic eliminates all the code and complexity from the integration, except for the core business logic.  Put another way, the integration is as simple as possible.

Any reduction in complexity may translate to cost savings although not always on a 1 for 1 basis.  However, it is generally true to say the simpler the solution the less expensive it is to create and maintain.

The Threshold

So simpler is better.  However there is a threshold of simplicity whose importance cannot be overstated.  

The threshold where a full blown software engineer or devops resource is not needed for implementation or maintenance.  Below this threshold the service become a force multiplier for an organization. 

Expanding the user base to include the broader technical population of the company that fall short of develops of software engineer can make a huge difference for many organizations.  Enabling this population means they are all enabled then to solve their own integration needs.  They no longer have to make a business case justifying the cost of the solution.  They don't they have to wait for access to software engineers or devops resources to become available.  They don't need those same resources for maintenance or updates as well.  This also allows for smaller problems to be solved as it is now cost effective to so; and almost every organization has a surprising number of these small needs that would never get met otherwise.

Let me reiterate because it is so important:

• Solutions can either be inexpensively developed or self developed
• Self developed solutions are done on-demand, whenever the user has time.
• Solving smaller problems is now cost effective and possible.

API Design

In order to achieve this democratization threshold, the API design must stay focused on the tooling and use cases appropriate to the broader user base.

The goal is for the user base to be able to self develop and self maintain their integration.  This self-service approach to automation enables more of the organization to take advantage of the service at minimal cost.

One example, targeting a ubiquitous tool like curl as the foundation for service integration.  This would allow for easy to use documentation with many examples.  The users could copy and paste those examples messing to self service development and maintenance of integrations.

API Strategy Series: Control Point aka Transparent Reverse Proxy

 Whenever there is a transparent reverse proxy in from of an API, what is being created is a control point.  This is also sometime described as an intercepting proxy, inline proxy or forced proxy

Why create an API control point?

Each behavior that is pulled into a control point is a behavior the integrator doesn't have to implement.  This means simpler integrations, less cost for the integrators and more usage. 

Simpler Integrations

Pulling in any behavior that may normally live in the integration, into the control point eliminates that additional code and complexity.

Pulling in all the behavior that would be in the integration, except for the core logic eliminates all the code and complexity, except for the core business logic.  Put another way, the integration is as simple as possible.

Simpler integrations are cheaper to implement, cheaper to maintain, easier to understand, and easier to fix.

Integration Cost Reduction

Pulling in any behavior that may normally live in the integration, into the control point eliminates the development and maintenance cost of that additional code.

Pulling in all the behavior that would be in the integration, except for the core logic eliminates all the development and maintenance cost, except for that of the core business logic.  Put another way, the integration is as cost effective as possible.

Downtime Mitigation

Having a control point gives you the opportunity to respond when the upstream service is unresponsive or has known incorrect responses.  That control point response may be as simple as a 504 Gateway Timeout, or it could include cached responses

The API may have availability or load issues, and you may want to provide centralized retry and/or queuing logic within the proxy.  This eliminates the need for multiple implementations of retry and queuing logic on the client side.  It also prevents a bad retry implementation from occurring.

Limits Blast Radius

Many API endpoints don't handle a single bad actor appropriately.  They expect all integration to be well designed and implemented.

Standardizes Programmatic Behavior

 singly implemented in the control point it prevents a different implementation from each integration.

Extensibility Layer

The control point provides a place to extend the system without having to update the backend service. This may be especially important in legacy situations, third party services or programs, or other situations where the availability to the code doesn't exists, or the risk for any modification is high.