My question is around best practice of aggregating or grouping REST APIs. I have a scenario where there are many different vendors, data sources, etc. and I think grouping REST APIs would make a lot of sense to keep the system maintainable.
I have many scenarios where there will be a single API call triggering many other (similar) API calls to create the same entity in another system. For example for an example entity "user":
- Front-end calls REST API: PUT .../user
- What I envision is that the code listening on the above API will then make multiple REST PUT calls to let's say vendorA/user, vendorB/user, vendorC/user, internalSystemA/user, internalSystemB/user, etc.
Like this:
+-------------------+
+--------+ PUT +-----------+ CALL | Vendor A API |
| | +-------> | user +--------> | |
| | | +-----------+ +-------------------+
| | |
| Front | PUT +--------++ PUT +-----------+ INSERT +-------------------+
| End +------> | user +------> | user +--------> | Internal System |
| | +--------++ +-----------+ +-------------------+
| | |
| | | +-----------+ CALL +-------------------+
| | +-------> | user +--------> | Vendor B API |
+--------+ PUT +-----------+ | |
+-------------------+
+ +
+---------------------------------+
Internal REST APIs
Note that the example entity doesn't have to be "user", there are many entities that are going to have a counterpart on the vendor APIs.
The vendors in this scenario provide different functionality. But there might be multiple vendors who provide the same functionality (and the user will chose the vendor he wishes to use). For simplicity let's say example functionalities are
- Procurement,
- Human Resources,
- Management,
- Payment.
What is the best practice to group and nest REST APIs in such a scenario? Is it a good idea to group them by vendor or should they be grouped functional or by business entity? How would the URL look like?