Will ignore the process layer for now.
- You have an SAPI that returns addresses.
- You have to apps that uses addresses. One uses them to search for businesses. One uses them to validate the address when setting up a lease.
- Could you have a common XAPI that just returns addresses or should each app have its own XAPI?
More simply could you have one address XAPI returning data to multiple apps that would use that address info but possibly in completely different ways? This would also mean the app would have to change the data structure it sends and receives.
To further compound this. The address XAPI/SAPI might be the only mule component for the each application.
Anurag Sharma (Nagarro) 
Forum Ambassador
Hello @Michael Fesser
Given Your Scenario:
- For the application that searches for businesses using addresses, the XAPI might be focused on facilitating search operations, possibly involving filters, pagination, and specific result formats.
- For the application that validates the address for lease setups, the XAPI might need to perform checks against a standard of valid addresses, maybe even interacting with third-party services for verification.
Given these potentially different responsibilities and the principles of API-led architecture, it would likely be best to create separate XAPIs tailored to each application's requirements. Each XAPI can then fetch address data from the same SAPI but process and present it in ways that are optimized for their respective applications.
Remember, one of the main advantages of the API-led approach is flexibility. By decoupling the Experience layer from the System layer, you can easily modify or introduce new XAPIs without disrupting the underlying services.
