什么是设计DELETE以获得宁静资源的最佳方式

Question

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 eg 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 )

Answer 1

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 (eg 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 Employee s with managerId=400 , it makes more sense to GET those resources: GET /employees?managerId=400 , and then issue a DELETE on all the returned Employee s.