Mule API Led Connectivity Design Approaches for Experience API

Question

As part of our journey towards API-led Connectivity, we have to group our resources (i.e. API endpoints) into multiple Mule applications for the experience APIs.
In order to have meaningful names for the Mule applications while maintaining the maximum re-usability, rather than associating the consumer names with the application names (which makes the experience API tightly coupled with the current application landscape), we propose to have Mule application names to reflect the essence of the business.

The list of the options are as follows. Which one do you think is more ideal? What approach have you used in your organization?

1. based on Channel/Consumer A dedicated experience API for a consumer such as WEB, CRM, Mobile etc.

uri examples:

www.example.com/example-**web**-application/v1/  
www.example.com/example-**crm**-application/v1/
www.example.com/example-**mobile**-application/v1/

Pro's: - applying channel specific policies is easier, management becomes easier, smaller outage window

Con's: - reusability reduces and chances of duplication of objects across api's increases

2. based on Business Domain Company data model is used. Eg - Customer, Product, Payment etc.

uri examples:

www.example.com/example-**customers**-application/v1/
www.example.com/example-**products**-application/v1/ 
www.example.com/example-**payments**-application/v1/

Pro's: - promotes reusability, channel agnostic, same api can be used across different consumers.

Con's: management might get complex, larger outage window, multiple consumers might be impacted

3. based on Customer Journey
   This approach is tied to the customer's lifecycle with the organization. Eg - Prospective Customer --> Lead --> Engage --> Payments --> Customer Retain

uri examples:

www.example.com/example-**prospect**-application/v1/  
www.example.com/example-**lead**-application/v1/
www.example.com/example-**engage**-application/v1/

Pro's: channel agnostic, same api can be used across different consumers.

Con's: can get increasingly big and further breakdown might still be required

Thanks.

Answer 1

As far I understand your question; you would like to know what URIs to be using for the endpoints of the experience APIs, right?

Based on a recent blog entry from mulesoft (July 12 2017).

Experience APIs are:

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. An Experience API is usually created with API-first design principles where the API is designed for the specific user experience in mind.

Based on the examples from MuleSoft and my understanding, the experience APIs are created for one given "experience"; web, virtual reality, mobile, etc...

You are trying to create an API for a given special experience to make the consumption of the API easy for this specific client.

According to my understanding the main goal on this level is not the re-usability. You focus on re-usability on the System API and Process API level, but the Experience APIs are supposed to make the life of the developers of the different clients easier by providing exactly the interface and data they need so they don't have to communicate directly with the system and process APIs, but they get a tailor-made API, suiting exactly their special needs.

Since the experience API is tailor-made for the special experience / channel / client-application; I think respresenting this in the URI is a good idea.