Closed blinkdog closed 4 years ago
Could also do something like:
PATCH /api/files/UUID
{"locations": ["site": "zzz", "path": "zzz", "archive": true] }
and just expect that PATCH knows to do the right thing and add a location, without overwriting the whole location object.
Though maybe you lose the ability to delete locations then?
I think changing PATCH like that opens up confusing semantics for the route.
Right now, the semantics are simple and clear: All keys provided in the PATCH body overwrite the keys in the record.
If we treat the "locations"
field as additive, this would remove the ability to delete locations, and it adds a special exception case for this one PATCH route.
If we said 'locations is additive when provided as the only key in the PATCH body' we could delete locations by providing more keys (i.e.: using the original PATCH behavior), but it still a special exception case with different semantics.
Conversely, the raison d'être for POST is to create resources and sub-resources.
The semantics implied for POST /api/files/UUID/locations
seem simple and clear to me.
And the PATCH route can keep its semantics as-is.
Works for me
Resolved in #45
While coding Long Term Archive, David suggested that we add an API for adding locations server-side to avoid a GET/PATCH round trip when we've already got the UUID.
https://github.com/WIPACrepo/lta/pull/48#discussion_r334153077
I imagine it would work like:
POST /api/files/UUID/locations
{ "site": "zzz", "path": "zzz", "archive": true }
Opening this issue to ensure we don't lose the idea.