One API or Two APIs one for internal use and the other for external use

Question

I follow the Layered architecture Like this:

But with two differences:

• I use Blazor Assembly for UI Layer.

• I have API layer(REST) In between the presentation layer and the service layer.

---

My question is related to the Api design.

If I design the solution for HR system and for example It has three modules:

• Recruitment.
• Performance Management.
• Time & Attendance.

and each module of these has sub-modules.

So I have two questions here.

1. Should I create one API for the whole HR system with multiple areas or one API for each module of these or one API for each sub-module?
2. Should I create another API for external usage (I mean one or more tailored for the HR system and another one for external systems like Procurement system for example) or just aligned with one? because when I asked about this some people said:

API endpoints must be UI agnostic. Tailoring APIs for some clients defeats the API ideas and purposes. The best design practices tell us to create APIs that express our backend store to the outside world regardless who is the outside world.

and others said It's totally fine to have two types of APIs the first for internal use in the solution and the other for interacting with other systems and this's so common when we use client frameworks like React or angular or blazor assembly .

Answer 1

Without knowing the specifics of your system, what you describe seems to indicate multiple APIs would be the better model.

You have described:

• Different deployment locations (DMZ, LAN etc.)
• Different development roadmaps (as per the comment by @John Wu)
• Different security considerations (DMZ, LAN)
• Different consuming systems (including UI) by audience (a recruitment candidate is not going to be using a system that exposes procurement functions)
• And also different authorisation and authentication methods by audience (HR, Hiring managers, Applicants, Staff, procurement officers)

I must admit I find this:

The best design practices tell us to create APIs that express our backend store to the outside world regardless who is the outside world.

Naïve or dangerous. It's true to a point but at some level you only want to expose certain parts of your enterprise (backend store) to certain subsets of callers (audience).

Tailoring APIs for some clients defeats the API ideas and purposes.

Not at all. As I noted above, a recruitment candidate is not going to be using a system that exposes procurement functions.

For completeness, I do agree that

API endpoints must be UI agnostic.

Subject to domain constraints noted above.

Answer 2

APIs that are combined must be deployed together. APIs that are separate could be deployed independently. So an API is, among other things, a unit of deployment.

Since your internal API may be deployed on an internal network and the external API will be on an external network, they will need to be deployable separately. So they should be separate APIs.

In my experience, compensation systems, especially when they contain commission structures, tend to change fairly frequently. In contrast, a timesheet system pretty much stays the same forever. So it is likely you may need to be able to deploy the compensation more often. In that case, it would be convenient if it were a separate unit of deployment, i.e. a separate API.