Designing Private, Partner, and Public APIs: What’s the Difference?

One of the defining characteristics of an API is that it should be reusable, but that doesn’t say much about the scope of an API, i.e. who the intended consumers are. A popular distinction to make is between privatepartner, and public APIs.

  • private API is consumed within an organization and not intended to be exposed to consumers outside of the organization.
  • partner API is consumed by partners of your organization, meaning that there is an established relationship and some framework (often some form of contractual agreement).
  • public API is intended to be consumed by anybody interested in the API, and does not depend on or establish a close relationship; the goal is to make consumption easy, and to attract as many consumers as possible.

Does this distinction translate into differences in API design? It very well might: after all, the most important success criterion of an API is that is drives value. If it takes a specific design to better do that, then it makes sense to design an API differently based on the private/partner/public distinction.

There are four possible distinctions between private/partner/public APIs that may be used as design constraints for specific design decisions:

  • Domain Knowledge: How extensive is the domain familiarity that you can build on when designing the API for the intended consumers?
  • Relationship with Consumers: What is your relationship with consumers, and how does that translate into API design decisions?
  • Security/Threat Model: How are identity and authorization established, and what it is the threat model that you are using for your API consumers?
  • API Landscape Context: What is the API landscape that you are designing for, and where some design coherence would be beneficial?

Always keep in mind that treating APIs as products is a good idea, and that designing these products for their intended consumers will help you to make better design decisions. Learn more about these constraints and how they can be used to improve API design.

If you liked this video, check out Erik’s YouTube channel for more “Getting APIs to Work” content.

Previous articleTranshumanism: The Next API Will Be Human
Next articleHow to Globally Access Variables and Functions in Titanium
Digital Catalyst, Erik works in the Axway Catalyst team and focuses on API strategy, API programs, and API platforms. His main goal is to make sure that organizations make the right decisions for using APIs as the foundation of their digital transformation initiatives. Erik has a Ph.D. from ETH Zurich, is the author of many articles, papers, and books. He is a frequent speaker at global API events and contributes to standardization activities to help improve the way APIs are designed, managed, and used."

LEAVE A REPLY

Please enter your comment!
Please enter your name here