What if DELETE has side effects -- how are changed records returned?

Hi Everyone,

I’m used to having to return other records on a DELETE in Ember Data – specifically records that are relationships of the deleted record. This is necessary so that Ember Data maintains a current picture of the server-side relationships, so these can be reflected on the client.

This does not seem possible if:

204 No Content

A server MUST return a 204 No Content status code if a deletion
request is successful and no content is returned.

200 OK

A server MUST return a 200 OK status code if a deletion request is
successful and the server responds with only top-level meta data.

JSON:API — Latest Specification (v1.1)

Seems like included records aren’t allowed in the 200 OK case, so how can the client be maintained current? Should the server not manipulate relationships in this way any longer, and leave it to the client? (In other words, the relationship must be unlinked explicitly by the client before deletion??)


I’m confused by the question. Are you trying to do a cascading delete (i.e. remove related resources as well as the DELETEd resource)? Or are you trying to prevent a cascading delete (i.e. remove only the DELETEd resource) but see what other resources the related resources link back to?

Thank you for the reply.

As an example, suppose a resource is deleted, and – as a side effect – the relationship on a related resource is changed server-side. I am used to returning the related resource, containing an updated relationship that no longer contains the foreign key (or resource identifier, if you will) of the first resource.

There is no cascade – only the first resource is deleted, and the relationship on the second resource is modified.

In this example, all that is changing (besides the deletion) is the relationship on the second, related resource. In my current paradigm, the only way to keep the client up-to-date is to return the related resource.

As a side note, I inspected the current Ember Data source, and it appears that the JSON serializer treats the response from a DELETE much in the same way as other methods. Thus, this perhaps less practical, and more a question about the JSON API specification.

Thank You!

Ah, so you mean something like having resources A, B, and C, with C currently related to A. When you DELETE resource A the server updates C so that it is now related to B. But the client still has a stale representation of C, so the client thinks C is related to A. Is that correct?

I don’t see why this is any different from a scenario where the same resource can be updated by different clients. You always have the problem of stale representations. You can either deal with this by versions / last-modified timestamps / Etags or by having the client subscribe to receive updates for resources it is interested in. I don’t see any concerns specific to DELETE operations. Or have I misunderstood?

I think that you’re right @jlangley about the point. I’m facing the same problem with cascading on a DELETE request. Could I use the 200 OK status code on my DELETE request and fill the meta member to include non-standard informations like the resources affected by the deletion (ie. the children deleted)?