1

I have a rest api with a type "Entity", this Entity has a list of children which themselves are also type Entity

Accessing the resources is as follows:

Get Children of an entity:

GET /api/entities/{id}/children

Get Single entity:

GET /api/entities/{id}

For removing resources I currently have the following planned:

Remove child from parent but keep child resource in database (delete ONLY the relation):

DELETE /api/entities/{id}/children/{childId} (calling GET /api/entities/{childId} will still return this resource!)

Remove entity from database:

DELETE /api/entites/{id}

Is this the common practice in REST API design for differentiating between removing a relationship vs removing a resource? Or is it expected that the child resource will be both removed from the hierarchy and completely deleted as well? What are the common ways to differentiate these two actions?

Claude Hasler
  • 396
  • 1
  • 14
  • 1
    A Delete and a cascade delete are terms often used on the data layer not on the edge layer, with that said this detail shouldn't be exposed to the caller... one thing worth mentioning is that DELETE operations are **idempotent**, means that it can only be called once, and the second time it called its should return 404 Not Found, here you are allowing it to be called on an already deleted entity.. I suggest a PATCH call for a relationship update, It's seems more of an update than a Delete to me. – SaleemKhair Jul 20 '21 at 12:15
  • Thank you, this makes sense – Claude Hasler Jul 20 '21 at 17:54
  • 1
    "here you are allowing it to be called on an already deleted entity." No, the resource `/api/entities/{id}/children/{childId}` was deleted, so `GET /api/entities/{id}/children/{childId}` should return a 404. But `GET /api/entites/{id}` doesn't have to. – nicoqh Dec 19 '21 at 15:18

0 Answers0