How to model availability of PATCH/DELETE

#1

I have an API that makes frequent use of links for many kinds of operations (e.g. confirm an order). When these links are not available, that means the operation is not allowed.

However, I see no parallel to “link missing = operation unavailable” when it comes to PATCH and DELETE. According to the JSON-API spec, these requests are sent to the resource’s self link. But the self link in general allows GET, PATCH and DELETE, so I can’t remove the link if e.g. deletion is not allowed.

A way that seems consistent with other link operations and with hypermedia is to add separate links called patch and delete that are identical to the self link, but which can be removed from the response when the respective operations are not allowed. However, this seems to run counter to the JSON-API spec, which says that GET and PATCH should be sent to the self link.

What I am currently doing is simply having property attributes called something like canDelete and canPatch. But then I am special-casing these two operations among all my other links. This would also be the case if adding e.g. a meta.verbs list to the self link. So it feels like no more than the lesser of the two evils, so to speak.

How are other people communicating whether PATCH and DELETE is allowed?

0 Likes

#2

I often use the first option you mentioned, however, model it to our data, e.g. canConfirm, so it feels less ugly and more in a way you would talk to end-users.

Another one I use is letting other attributes explain a status, e.g status: "invoiced" means you won’t be able to use DELETE, and the docs should then explain that you can’t delete an already invoiced order.

Both assume the client knows the nature of the data of the server and it can’t be used as a generic client which can consume any data. As far as I known that is not the aim of JSON:API either.

0 Likes