1

Trying to find out what is a good way to design a delete.

trying to explain using example:

I have a resource for Employee. The employee has the following fields

Employee{
    String firstName
    String lastName
    String emailId
    String managerEmployeeId
    String employeeId
}

I want the ability to delete the employee using any of the fields e.g. firstName , lastName , employeeId , or managerEmployeeId

How should my resource paths look ideally

Option1: is this a good option ? yes ? no ? why ?

/employee/id/{employeeId}
/employee/firstName/{firstName}
/employee/lastName/{lastName}
/employee/managerId/{managerId}

Option2:

use of query params

    /employee?id=100  ( to delete employee with id 100)

    /employee?firstName=Tom&lastName=Winn (to delete an employee named Tom Winn)

   /employee?managerEmployeeId=400 (delete all employees having manager id as 400)

Option 1 looks very RPC-ish to me

I like the second option but I find it very error prone since the fields have to be specified.

In the 2nd option I don't like the idea of having a param named firstName and then mapping it to a firstName field in a Java class Employee. Is this a used paradigm in the industry ?

Further this is for a backend application with xml and written in java( use of loose field names looks very un-java to me)

I would like to understand what is being followed in the industry ( specifically for a strongly typed java+xml based rest systems built in jersey , restEasy or Spring )

SK176H
  • 1,319
  • 3
  • 14
  • 25

1 Answers1

2

My vote would go for (a slight alteration of) option 1.

DELETE /employees/{employeeId}

There's no need to specify /id, I can't imagine there's ever going to be any confusion (unless you have an employee named some bizarre UUID...). This also leads me to why I'd say the others were a bad idea:

There should only ever be one Employee with that id, so there is no room for ambiguity. There are likely to be many with the same firstName, lastName (and even combinations may not be unique).

If you put /id in the string, it implies (to me at least) that there may be some other way to uniquely refer to that resource (e.g. the /firstName or /lastName which you suggest); omitting it leaves it clear that's the only way you support referencing a specific Employee, and that if they want to find the one with a specific firstName and lastName, it should be retrieved with a GET /employees?firstName=Tom&lastName=Winn type request.

Query parameters in a DELETE sound risky to me, and more like something whatever is calling your service should be in charge of. If you want to DELETE all Employees with managerId=400, it makes more sense to GET those resources: GET /employees?managerId=400, and then issue a DELETE on all the returned Employees.

BeUndead
  • 3,463
  • 2
  • 17
  • 21