1

I follow the Layered architecture Like this:

enter image description here

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 .

2 Answers 2

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.

6
  • I don't know how U conclude all these things! I don't say any thing about these points in my question! and I don't understand what's the meaning of this: a recruitment candidate is not going to be using a system that exposes procurement functions. Aug 20, 2021 at 13:23
  • I summarised these points from many, many years of API design. Perhaps we are at cross purposes - Happy to elaborate where you think I've missed the intention. You mentioned procurement and recruitment as parts of your system. They are wildly different and so probably should not share an API because they have different audiences and authorisation/authentication, data and function requirements. Perhaps "a system for recruitment candidates is not going to need procurement services" makes it clearer? Aug 20, 2021 at 16:06
  • There's misunderstanding here, I agree that I need 2 APIs one for HR system and another for Procurement My 2 questions are not about this. It's about should I make one API for the whole HR system with multiple areas for each subsystem inside like recruitment or should I make one API for each subsystem. this's the first question. The second one I'm asking about should I create two types of APIs for each system one used internally inside the system and the other to interact with other systems or the internal one enough and should make it more generic and not tailored for this system. Aug 20, 2021 at 16:20
  • 1) Lots of APIs for the reasons in my answer! Different audiences should have different APIs. How your system is structured is not necessarily relevant (though it might be). 2) Not sure I understand 100% but probably the same answer for the same reasons. An internal API is a wildly beast from a public one. Aug 20, 2021 at 16:35
  • 1-HR system has the same audience , so why should I create multiple APIs for each sub-system in it? 2-I mean that If I have two separate systems one for HR the second for Procurement and each one has its own API. Should I create another two APIs one for each system to interact together or no need for that. Aug 20, 2021 at 16:41
0

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.

1
  • Thanks, but your answer focus on the deployment specifically and my questions are more than that. Could U read the two questions again please. Do You mean by separate Api two types of APIs one for the internal solution and the other one for external systems ? Aug 19, 2021 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.