What is an Experience API? When should you make one? Isn't it inefficient to have a custom API/proxy for every API Consumer

[pranavchaudhary]

Hi,

I read about Experience APIs in one of the Apigee EBooks and just wanted to some more information about it.

1. When should one create an Experience API?

2. How is it different from a regular API?

3. What is the purpose of it?

4.What is the best practice around API consumers calling APIs to request services? In the sense

a) Is it a fair expectation of client applications/API Consumers to call APIs (GET /Products POST/Accounts) with payloads containing the API field names?

b) The alternative would be to cater to the API Consumer's database table fields and perform some transformation logic in Apigee using JS or XSLT to convert that to the API field names. Is this what an Experience API does? It just sounds inherently inefficient cause you would have overhead on your Apigee Server (On-Premise Deployment) in terms of custom logic...yet this seems to be the leading practice in System Integrations.

Sorry I'm just a little confused and would love some clarity from the Apigee Experts.

@Chris Hood @Dino

[ChrisHood]

This topic is a theoretical discussion.

At the end of the day, an API is an API is an API, it's what you do with the API that counts.

Best practice is to ALWAYS design APIs from an Outside-in perspective, meaning you look at what your customers need, and then work inwards to build that "experience" for them. A more formal definition of outside in is:

A design and development philosophy that focuses on the overall digital experience of customers starting with how they view products and services on the outside of a company before flowing inward to connect with business processes and data systems.

I highlighted 3 words in this: experience, processes, and systems. In API design, we typically see 3 types of APIs.

1. Experience APIs - APIs that innovate and target user experience (loyalty programs, profiles)
2. Process APIs - APIs that help orchestrate, improve processes, agility (interconnecting service)
3. Systems APIs - APIs that unlock data, decentralize access (sso, legacy modernization)

All of these APIs should still be designed within a RESTful format, and be easily consumable by developers, whether those developers are building applications for external customers, internal employees, 3rd party partners, B2B, and so on. The API Consumer, must understand what the API does. This is why best practice is to build API Products, that identify what their specific use is.

• GET v1/products ---- I know this is about your products
• GET v1/products/shirts ---- I know this is about your products that are shirts
• GET v1/products/shirts/1234 ---- I know this is about a specific shirt.

The backend, database tables, logic, policies, are all hidden from the API Consumer. None of it matters to them. Your job is to create understandable APIs that can easily be used, no matter what their specific use case is.

My PERSONAL view on this: ALL APIs should be looked at as EXPERIENCE APIs. You would not need an API if you were not trying to improve an experience for someone. More so, in each example I outlined above, there is an opportunity for creating, delivering or improving user experiences.

1. Experience - innovate and target user experiences = create user experiences.
2. Process - help orchestrate, improve processes = get to market faster, improves user experience.
3. System - unlock data, decentralize access = meet user demands, delivers expected experience.

But as I said at the beginning, an API is an API is an API. Design it in an easy to understand way, from an outside-in perspective, and you'll always be able to keep up with the expectations of your users.

[AdrianK-MWNZ]

I generally agree with Chris's answer, but want to expand on part of it.  

>> Best practice is to ALWAYS design APIs from an Outside-in perspective

That's 100% correct, which leads to my point: an Experience API (perhaps poorly named) is an API's who's reason to exist is to facilitate efficient API usage for clients e.g. web clients, mobile clients, etc.

Imagine you have a UI that needs to fetch a bunch of data from one or more API's - if there's a lot of API calls, and the UI is particularly "chatty", this can be an issue where the client is talking over a network with poor latency.  the Experience API basically handles the orchestration and heavy-lifting to get the data assembled in a way that is efficient for the client, and provides it back to them.

Using an Experience API in this way, where it calls / orchestrates other API's such as Process and System API's is basically API Layering.