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

APIs are meant to be reusable, and thus should be designed so that potential API consumers find the API usable and useful. The API scope is one important design constraint that can help to inform API design, and thus to create a better API.

Private APIs are consumed within an organization and thus there is an existing and relatively tight coupling between API consumers and API producers. Partner APIs are consumed in the context of some partner program, and even though consumers are outside of the organization, there is an established relationship. Public APIs are consumed without such relationship, and thus there only is a very loose coupling between consumers and producers.

In this video, we look at four design constraints that are affected by the difference between Private, Partner, and Public APIs. We look at how domain knowledge, consumer relationships, security issues, and API landscape questions are affected, and how it's possible to design better APIs when taking these constraints into consideration.

00:00 Introduction
01:01 System APIs
01:35 Definition: Private/Partner/Public APIs
02:41 Four API Design Constraints
04:13 Domain Knowledge
05:31 Relationship with Consumers
07:08 Security & Threat Model
09:03 API Landscape Context
10:57 Wrap-Up

[miguelquintero]

..hi Erik..I have spoken to people that are of the opinion that even private APIs should be designed as public APIs.... thoughts?

[younesybmlmv]

That is What o search for, i will give a presentation of api, and i will additionne some constraint:, infrastructure .
Why?
Because in some companies de have public (client and prospects), we have parteners that share with us the same intranet or private cloud( we dont have rights to expose sensitive data in intetnet), we have parteners out of our groupe (de Need some DMZ servers while for group partener, opening flows is suficients),
I'll add the process constraint, because i open one api for policy subscription, the some process need to be acepted for us, and a sub process for accepting an other kind of contracts, this sub process is delegated to other partener.

[patricekrakow]

TL;DR | My (personal) answer is THERE MUST NOT BE ANY DIFFERENCES!

I am usually quite strong saying that, according to the Jeff Bezos Mandate point #5, there MUST NOT be any difference in the way you *design* Private, Partner, and Public APIs.

As a reminder, the Jeff Bezos Mandate point #5 says: << All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. >>


I also like to say that a "Private API" is just a "young" API that has not yet find the business case to become a "Public API". And, when that happens, you can be in two rather different situations: (1) you have strictly followed the Jeff Bezos Mandate point #5 and you ready to get the market, like Jeff did with AWS, or (2) you have not and ... you are not as successful as Jeff ;-)