1 Service end-point vs 3 individual end-points for Create/Update/Delete in CRUD | Architecture

Question

I am having this question about having CRUD services built, I should be able to create, update, delete and get the records from the DB.

For easy understanding. I will use an example of a Company to which I should be writing services to perform the CRUD. I should add an employee, update an employee, delete an employee, get the list of employees that work for the company.

The below Object would be used as a request payload for Create/ Update/ Delete and The List of the EmployeeDomainObject would be used as the response for the Get request

EmployeeDomainObject { "firstName": "string", "lastName": "string", "id": "string", "status": "ACTIVE" or "DELETE" or null }

• Should I go with 2 services?
  • 1 end-point for Get to get the List based on the company Id
  • 1 end-point for Create/Update/Deletes that will accept the EmployeeDomainObject as the Request body and update the DB accordingly based on the status.
    • If the request has status: null --> New Record ID would be null, on save one dynamic Id would be generated
    • If the request has status: "ACTIVE" --> Update the record based on the ID
    • If the request has status: "DELETE" --> Delete the record based on the ID
• Should I go with 4 services?
  • 1 end-point for Get to get the List based on the company Id
  • 1 end-point for Create to create the employee based on the EmployeeDomainObject
  • 1 end-point for Update to update the employee based on the id in the EmployeeDomainObject
  • 1 end-point for Delete to delete the employee based on the id in the EmployeeDomainObject

Scope and Requirements of the services: 1. Robustness 2. Maintainability 3. Which is more Service driven? 4. Scalable/ Extensible

Answers Appreciated

Answer 1

It really depends on how you plan to implement the service. If you're going to use an established framework such as Spring, then you would most likely use the 4 endpoint method and not have a status field as the status would be implied by the HTTP verb (GET/POST/PUT/DELETE).

What you have is really RPC (Remote Procedure Call). The status field is the "method" to invoke. Where pure REST would use HTTP verbs, RPC would use this type of method invocation. So if you plan to build the service from scratch without using a framework then you could go with one endpoint. I don't see the point of having only 2 endpoints when you can add another status field:

EmployeeDomainObject 
{
   "firstName": "string",
   "lastName": "string",
   "id": "string",
   "status": "ACTIVE" or "DELETE" or "RETRIEVE" or null 
}

and use POST. It's not REST but you're not asking whether it's good REST or not.

There's nothing "wrong" with using the above, especially if you're going to build the service from scratch (perhaps it's resource constrained etc).

The endpoints are just the way the client interacts with the service. Whether those interactions arrive via 4 REST-style endpoints or 1 RPC-style POST is irrelevant. The client just does what it needs to do.

The consequences are for the server. An established REST framework such as Spring will give you a big start but tie you in to 4 endpoints. If you're free to design the server side as you wish, then there's nothing wrong with the RPC-style approach. You can still log/audit/handle permissions on the service but you'll likely need to code them yourself.

If you're planning to build something big and hire lots of programmers, then you'd likely want to go with the flow and use the 4 REST-style endpoints and an established framework, in order to hire from a wider talent pool, rather than hiring and training on your custom designed system.