API identity: Is my API gold or blue?

You all remember the photo of the dress which went viral on the internet a couple of years ago. Viewers of the photo disagreed over whether the dress pictured was colored black and royal blue, or white and gold (I think it’s white & gold), APIs have a similar aspect; their ‘color’ depends on who is looking at them. APIs have an identity and that identity changes depending on who is looking at it.

Developer on the consumer side

Does the dress fit? Does it solve their pain point? Can they get their job done?  Will it give them a “Wow”? Will it help them hit their sprint goals? What is the API “unboxing” experience like? Is it well documented, supported? It’s about the entire package of the API and not just the color (see UX).

Developer on the provider side

This developer will only see the dress at the initial design and establishment of the API contract. At this point the color is important but only if a stated requirement from the Product Owner.  Thereafter they only see the internal stitching of the dress and how it is made up of existing components – how they stitch together their dress based on the existing services and datastore etc.

Quality Engineer

The engineer will confirm that the API adheres to the stated colors but will look for other colors in the visible and non-visible spectrum. They will also look at the dress size to see if it comes in -XS or infinite XL. And look to see how much load the API can take when it goes viral like the above photo.

Operations

DevOps will see multiple dresses and they could be any color. They’ll view the dress in various phases of its lifecycle and how it will be promoted through various environments. They’re not concerned with the color, all dresses have a color – just ask the quality engineer. They are concerned with the SLA of the API and that the systems that support the API are available. 

Security/compliance office

The multi-color aspect of the dress is interesting but they don’t see this “feature”; they’ll see an API as a potential security breach and will be looking to see if the API is secured with appropriate authentication and authorization. Meanwhile, in the back of their mind, they’ll be thinking about the OWASP API Security Top 10.

UX

Yes, the dress has two colors, but that is a bad user experience as it’s confusing the viewer. UX is concerned with the usability, accessibility, and pleasure provided by interaction with the API/dress – all of these are important considerations for the API as developer experience is enhanced to meet the consumers’ needs.

Product Manager

The PM is delighted that the initial prototype of the dress has found unique values in the “chameleon” fabric that early adopters love. Is working out the target market to be successful with the dress and to meet their business goals. Is the dress an “haute couture” piece versus a less complicated design that is a suitable template for high-volume reproduction? Walmart versus Dior?

Marketing

This team sees the chameleon-colored dress and is delighted with it. The dress has gone viral, they couldn’t have asked for a better marketing campaign to attract a community of consumers to try their API.

 There is no spoon

C-level

When a C-level exec looks at the API they don’t see the API at all — there is no dress. The primary concern is “whatever I’m looking at does it help me with my business goals?” The exception to this would be the CTO or CIO who sees the API in terms of how it helps to drive innovation, digital transformation, or new digital business models in support of the business goals.

As you have seen the identity of an API will change depending on who is looking at it. Each viewer will have a lens through which they will look at the API. It’s important during all aspects of an API’s lifecycle that you understand the audience that is looking at the API and provide them with the appropriate information.