0

Our Platform architecture is built around API Led Connectivity which was designed by Mulesoft(Doc).

So this architecture helps us to identify and classify our microservices. The tricky part here or maybe the part that I am confused about is the experience API. So I want to explore a few questions in the context of one app -> one platform(reusable). Can we have multiple Experience APIs? If Yes then how do we identify a candidate for an Experience API?

Mulesoft defines the Experience Layer as

Experience Layer: Data is now consumed across a broad set of channels, each of which wants access to the same data but in a variety of different forms. For example, a retail branch POS system, e-commerce site, and mobile shopping application may all want to access the same customer information fields, but each will require that information in very different formats. Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel.

So if Experience APIs are not separated they can quickly become bloated with lots of things (In the name of transformation & adding app-specific logic). So how much should an experience API do in that regard? A general way of approaching them would be helpful with some practical examples.

Jeson Dias
  • 883
  • 2
  • 11
  • 26

1 Answers1

0

An Experience API is designed to simplify the way data is accessed by specific client types.

For example you have a requirement to expose Order Information from SAP to Desktop and Mobile applications.

System Layer

  • SAP Order API (This API gets the raw data out of SAP)

Process Layer

  • Order Information API (This API provides a canonical view of the order data. Which is accessed directly by Desktop clients)

Experience Layer

  • Mobile Order API (This API provides a reduced set of data and pagination from the Order Information API as mobile clients have data restrictions)

Keaton

Keaton Victor
  • 91
  • 1
  • 5
  • "Can we have multiple Experience APIs for a single client? If Yes then how do we identify a candidate for an Experience API? " - Any thoughts on this? – Jeson Dias Aug 07 '19 at 11:20
  • 1
    Yes. Much like you would break up your "Process Layer" APIs by domain contexts... such as Invoice, Customer, Contact, Order etc.... You would do the same for the "Experience Layer" such as Invoice Mobile, Invoice IOT, Invoice Printer, Customer Mobile etc. Putting all these into a single API would be a bad idea. – Keaton Victor Aug 08 '19 at 12:16
  • @KeatonVictor, I was having a similar question and stumbled on this post. Thanks for your answer. To clarify, lets say I have 2 clients - Web and Mobile, both need customer address, but 2 totally different address formats. So your recommendation is to have 2 experience APIs -- -1) GET: /customer-web/address 2) GET: /customer-mobile/address. Is my understanding correct? We are actually identifying the 'caller' in the URL. Is it acceptable by REST standard? – Joe Jan 28 '21 at 16:29
  • Hi @Joe Yes I would recommend 2 experience API's. The role of an experience API is to provide a specific view of data which is tailored for the client (e.g Web, Mobile, IoT Device)..... Using the URL to represent the different clients is one option but not best practice. A cleaner option would be to use one of the following. (1) Customer header e.g X-Consumer (2) use subdomains e.g client-1.myapi.com/address (3) Make the API consumer aware, such that it will tailor response based on authenticated user.... Each with pro/cons. Ping me if you want to discuss options more keaton@pattnr.com – Keaton Victor Jan 29 '21 at 23:06