WIPACrepo / file_catalog

Store file metadata information in a file catalog
MIT License
1 stars 4 forks source link

POST /api/files/UUID/locations #44

Closed blinkdog closed 4 years ago

blinkdog commented 4 years ago

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.

dsschult commented 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?

blinkdog commented 4 years ago

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.

dsschult commented 4 years ago

Works for me

blinkdog commented 4 years ago

Resolved in #45