Why we use Resource-oriented design

It is definitely better to develop atomic APIs, for various reasons related to maintainability, scalability, and clarity.

Atomic APIs are endpoints that perform a single, well-defined action. For example:

POST /users → Creates a user

GET /users/{id} → Retrieves a user

PUT /users/{id} → Updates a user

DELETE /users/{id} → Deletes a user

In contrast, generic (or overly “rich”) APIs attempt to handle multiple operations through a single endpoint, for example:

POST /users with a parameter action=createOrUpdateOrDelete → which may create, update, or delete depending on the payload.

✅ Benefits of atomic APIs

Benefit	Explanation
Clarity	Each endpoint does one thing only, making it easier to understand and document
Maintainability	Code is more modular and testable, with fewer scenarios to manage in one place
REST compliance	Better reflects REST principles and improves integration with standard tools
Reusability	Easier to combine atomic calls to build complex client- or backend-side functionality
Security	Easier to apply granular permissions for each type of action

❌ Risks of generic APIs

Ambiguity: it's not always clear what the endpoint will do

More complex testing: multiple logic paths in a single endpoint

Confusing error handling: harder to diagnose what went wrong

Limited scalability: harder to separate responsibilities or distribute load

For detail

Please visit for more detail Resource-oriented design