Internal APIs == External APIs

Internal APIs == External APIs
This post was published on the now-closed HuffPost Contributor platform. Contributors control their own work and posted freely to our site. If you need to flag this entry as abusive, send us an email.

I am getting tired of listening to "Oh, we're building internal APIs, we don't need API management."

*start rant*

  1. You actually know that this API will not be externalized?
  2. You think internal calls are secure?
  3. You do not care about developer adoption of your internal services?
  4. You do not crave visibility into who calls whom?
  5. You are not adopting cloud?

*end rant*

Now that I have calmed down a bit :), let me explain. There's very little difference between an internal API and an externalized API. You will agree that each internal service needs an interface. The "contract" is that the interface will change slowly--though the implementation underneath it could change.

This is because the callers are hardwired to call these interfaces. Modern interfaces are RESTful APIs (though there might be other API patterns, such as gRPC).

These APIs need API management

While pushing the responsibility of the interface to the service is the right model, there are many concerns that still need to be addressed around these APIs:

  1. Versioning The interfaces can change. They change slowly, but they still change.
  2. Security All services have to operate in a zero-trust environment--just because they're internal does not mean that perimeter security will suffice; can it really trust the caller?
  3. Visibility With API sprawl, what's really going on? Which are the common patterns, where are the bottlenecks, what is broken, what is working?
  4. Discovery What services exist, how many do similar things?
  5. Governance How does a central team govern (lightly) the right structures and policies?
  6. Traffic management Services will misbehave--or run into limits.
  7. API lifecycle Scaffolding, documentation, test driving.
  8. Developer onboarding While the developers in this world are likely internal, they should still be treated as if they are external. That way, one can pivot to externalization of a service if needed.

Be prepared to externalize

If one looks at API management for externalized services, these sound very similar. Some API management capabilities like mediation, caching, OAuth, and deep traffic management might not be needed, since we should assume that the called services have clean APIs and are built to scale. Whenever that assumption is false, however, these services are also needed.

Equally importantly, treating every internal service as externalizable gives you business options you wouldn't have had otherwise.

That is why Trustpilot runs API management on almost all its APIs--through the Apigee layer.

Don't be boxed in by thinking APIs but not thinking API management for your internal services. You will not succeed.

Popular in the Community

Close

What's Hot