Consider changing Petclinic URIs for PUTs and DELETEs to /{id} instead of current /{id}/edit [SPR-5498] #10170
Description
Chris Beams opened SPR-5498 and commented
Essentially this involves setting the form action manually for each PUT/DELETE (and POST, for that matter) scenario.
Currently PUTs and DELETEs are being issued against the URI that was used to GET the form.
e.g.:
GET http://localhost:8080/petclinic/owners/1/edit
followed by a:
PUT http://localhost:8080/petclinic/owners/1/edit
it is more correct to do the put directly against the entity resource, not against the 'form resource'. e.g.:
PUT http://localhost:8080/petclinic/owners/1
Same with deletion:
DELETE http://localhost:8080/petclinic/owners/1
In the case of POST, it's a little more interesting:
GET http://localhost:8080/petclinic/owners
Renders a list of all owners
GET http://localhost:8080/petclinic/owners/new
Renders the 'add new owner' form
It's an open question, then, whether adding a new owner should be:
POST http://localhost:8080/petclinic/owners/new
or directly against the 'collection of owners' resource:
POST http://localhost:8080/petclinic/owners
I'm leaning toward the latter. The only caution here is that it leaves the door open for users to make an honest mistake when coding a form against this URI. The user may intend to be issuing a search (GET) request, which should read as follows:
GET http://localhost:8080/petclinic/owners?firstName=Chris&lastName=Beams
If the user mistakenly submits the form using POST, however, they could inadvertently create a new entity!
POST http://localhost:8080/petclinic/owners?firstName=Chris&lastName=Beams
This is at once an elegant design and a great feature, as well as a 'dangerous' possibility.
This issue is a sub-task of #10156