The idea itself is valid.
I haven’t seen any problems since id
and codUsuario
form some kind of composite key to access this resource in which you want to remove OR both form a URL in which the set of these two information can point to a single resource, in a parent-child relationship.
I will give an example of each case. First, with composite key.
First example
If you want to remove a document in which the composite key is document type and its number:
/documentos/{tipo-documento}/{numero}
A request would be:
DELETE /documentos/CPF/12312312300/
Now let’s go to the second example.
Second example
You may have orders and products, and wish to access the product within an order (or remove it in your case).
/pedidos/{id-pedido}/produtos/{id-produto}
And the request:
DELETE /pedidos/123/produtos/3333
However, looking at the example he gave, his endpoint is very strange, it does not seem to be either of the two cases because it is not possible to see a natural relationship between id
and codUsuario
. We would need to understand the context behind this endpoint for a better solution. Perhaps, you are looking for something like this:
DELETE /users/{codUsuario}/addresses/{idAddress}
Yes, for me it also makes a lot of sense to use this way. I would just like to be sure to be following the REST standard. In my case I have a composite key N for N. Where it would make no sense to use an id for this table. At least, by default it is not used. An example of one of these tables I have is post_like, where the identifiers are usuario_id and post_id. Therefore, to excuse a post you would need to use a DELETE command /url+route/usuario_id/post_id
– alan
@Alan, if your intention is to like/neglect a post, I think you’ll be interested in seeing how Github controls star/unstar in their API.
– Dherik