Should one API be used for performing multiple task

If the API is to update dates in a table(PATCH Call),should the same API be used to calculate the earliest date and update it in another column of the same table.If yes should there be different error message to indicate which part of the API failed.

Details of the table: The table consists of employee details, so there are two columns where “when the employee joined” is entered and another column indicates which employee among a particular department joined first.

Great API question and it can have an answer that has a testing bias!

In my opinion, an API should perform a single, small task for the reason you expressed and to maintain some simplicity. To that end, a small, single, simple task is MORE testable than a complex set of tasks that cannot be easily isolated.

I agree with you that it will be difficult to provide feedback on which task succeeds and which one does not. While it possible to manage the tasks and their associated errors, that management would also require more testing. However, that kind of design seems like the start of technical debt, and could indicate to someone maintaining that API that this kind of design choice is acceptable. In my opinion, small/single/simple is a better choice for an API because that makes the API more testable now and in the future.


In my opinion, 1 API or any piece of code( Automation, in general) should be responsible for only 1 task. And we should have more specific purpose APIs/ function as opposed to general purpose APIs/ functions. This, in turn, makes maintenance or replacement of the code much easier and without affecting the overall behaviour of the test solution. If we have an API or a piece of code that caters to multiple tasks, it could lead to more bug-prone tests.

I think we need to agree on a definition of what you mean by an API? Since you mention the PATCH HTTP verb, I’m assuming you’re talking about a web API, and within a web API, it’s perfectly normal to have multiple endpoints. It sounds like you have something like:

PATCH {API_PATH}/{employeeId}/{startDate}

The next part you describe (“calculate the earliest date and update it in another column of the same table”) sounds really unusual. I think that the column you’re referring to there is also the “column indicates which employee among a particular department joined first.”? That is really strange in that it sounds highly de-normalized (repetitive), and if anything, if you want to cache that kind of data, it sounds like it would be a table suited for that kind of data (i.e. three columns of employeeId, startDate, and department).

If you don’t need to cache it (i.e. the table isn’t massive), it seems like a query against your current table would be able to handle this easily, something like the query outlined in sql - Highest Salary in each department - Stack Overflow.

If the actual question is should the PATCH update the cache, I think that really depends on the business need. I could see cases where the cache is updated on each PATCH, where it might be run regularly (like a cron job), or where there might be another endpoint to trigger generating that data.

For the original topic/question (“Should one API be used for performing multiple tasks?”), I’d say there’s nothing wrong with having multiple endpoints for many tasks within a given API.

This is a micro services type question and just the other day I read about nano services and why they should not exists. The reasoning went something like this. A microservice is a single purpose service that solves a business concern. Like UserManagementService. A nanoservice is a single function service, i.e. RegisterNewUserService. The argument was that they should not exist due to the ratio between the value and the separation of concern versus the overhead of store / build / version / release / document a single function. Of course as internet goes people did not agree and gave a counter example. Like validateEmail is a stateless function that can be reused across multiple services and should therefore be its own service.

As for an API I think good practice is to group concerns together in one API, but it’s all about trade offs and for me there is no should or shouldn’t. Furthermore APIs are by their nature meant to be consumed by something else. If you design your APIs in a way where every consumer have to make multiple calls across a multitude of APIs and endpoints to service a very common use case. Then the API is badly designed.