Stream: implementers
Topic: PUT to deleted resource location
Paul Church (Jun 18 2019 at 15:40):
Is it expected that a server which does not normally allow upsert to a client-defined ID will accept a PUT to the location of a deleted resource?
From the spec language in delete ("Resources that have been deleted may be "brought back to life" by a subsequent update interaction using an HTTP PUT.") and Update as Create ("...to PUT a resource to a location that does not yet exist on the server") it seems like the answer would be yes, but the connection between the two is not quite spelled out. If a deleted resource is considered to be a location that does exist on the server, the wording could state that more explicitly.
Lloyd McKenzie (Jun 18 2019 at 17:01):
A PUT to the location of a deleted resource is more like an update than an upsert as the record 'exists'. However, there isn't necessarily an 'expectation'. Servers that don't permit upserts can choose to support 'undelete' updates. (And similarly, systems that support upserts could choose for business reasons to prohibit 'undelete' updates.)
Grahame Grieve (Jun 18 2019 at 17:54):
Servers that don't permit upserts can choose to support 'undelete' updates
uh? since undelete is supported via 'upsert' I don't know how to make sense of that
Lloyd McKenzie (Jun 19 2019 at 01:11):
My understanding is that "upsert" means "create if it doesn't exist, update it if it does". In the case of a deleted record, the record 'exists' - it's just flagged as deleted, so it would always be an update, not an upsert, no?
Grahame Grieve (Jun 19 2019 at 01:13):
well, it's semantics, I guess.
Lloyd McKenzie (Jun 19 2019 at 01:22):
My point stands I think - someone could prohibit client-assigned ids on a true 'create', but could still allow resurrecting of a deleted resource. (And could similarly allow client-assigned ids on a create, but (for some reason) prohibit resurrecting deleted resources. Correct?
Michael Lawley (Jun 19 2019 at 02:15):
One distinction is about which fields are allowed to vary on an update. If it's an "upsert", then these wouldn't apply. If it's an "undelete/update" then I would expect they would.
Lloyd McKenzie (Jun 19 2019 at 02:54):
True. And you wouldn't want a delete followed by an undelete to bypass your 'update' rules. (e.g. changing the patient or prescriber on a MedicationRequest). In fact, that's probably important enough to call out in the spec. @Michael Lawley, care to submit a change request? :)
Michael Lawley (Jun 19 2019 at 03:31):
Last updated: Apr 12 2022 at 19:14 UTC
