resthttphttp-delete

How to send a compound primary key in a HTTP DELETE request?

I have a link table in my database with two columns, event_id and user_id. Both are foreign keys, and together they form a compound primary key.

Ordinarily when sending a DELETE request to my api, the URL would be something like https://myurl/api/v1/user/:userId, and the userId param would correspond with the primary key of a row in the User table, so I can uniquely identify which one to delete.

In this example however, I need to send two ids with the DELETE request to identify the correct row to delete. I am aware that it is possible to send a body with a DELETE request but it's not advisable to do so. What is the best way to handle this?

Solution

  • What is the best way to handle this?

    In most cases, it is okay to use POST. Produce a form that allows the client to provide the identifiers that match their needs. Removing/Scheduling the removal of the row from the database is an implementation detail hidden behind the API facade.

    In other words, it's OK to handle it as though you were capturing information via a web form.

    DELETE is used for resources, not implementation details. Which is to say, if we wanted to stop sending representations to client that send

    GET /0f7dde16-c413-4732-9f8d-b8e5c0dfb69f

    Then we in turn send this request:

    DELETE /0f7dde16-c413-4732-9f8d-b8e5c0dfb69f

    And behind the api facade, your server figures out how to implement that.

    The point here being that you rarely need to invent a new URI to delete a resource, because you normally use the same URI that you would use to read the resource.

    The case where you want to invent a new URI specifically so that DELETE can trigger some particular side effect is uncommon.

    But when this is the right direction to go, the usual rules of resource identifiers apply: you must to use an identifier consistent with the production rules of RFC 3986, and you should use a spelling that affords URI templates as described by RFC 6570.

    Beyond those two constraints, REST doesn't care; so choose any spelling consistent with your local conventions that makes the humans you care about happy.