Deprecate endpoints using an origin-id.
Depends on !144 (closed).
Test Plan
Install swh-storage with arc patch swh/devel/swh-storage!226
and run pytest.
Migrated from D1667 (view on Phabricator)
Merge request reports
Activity
Build has FAILED
Link to build: https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/562/ See console output for more information: https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/562/console
I agree that all endpoints using origin ids must be deprecated.
But maybe we should add their counterpart using
origin_url
argument instead of purely removing them.My main concern is that we have rate limiting in place for the api and some operations that were needed a simple call to an endpoint will now require querying multiple endpoints to get the same results.
Honestly, I don't know what is the best solution here. The concerned endpoints are handy for users that want to get relevant data associated to a particular origin.
We should check with @zack to get his opinion on this.
mentioned in issue swh-storage#1816 (closed)
So, I'm fine with the proposed deprecation, as written.
I don't think we should add workarounds (in the form of additional "shortcut" endpoints) at this point for a couple of reasons.
- first: we are not on a clock for //removing// the endpoints we are deprecating, people who really are concerned with the rate limit can still use the old ones
- second: in theory the change could be done without making using the API more expensive (in terms of rate limit) than before; the only reason we are not doing it right now is that, without query parameters, putting URLs in the same places where origin IDs used to be become ambiguous. I see that as a temporary matter anyway, which will be fixed when we switch to query parameters everywhere (and I'm not shocked at the idea of keeping the deprecated endpoints around until we do so)
Build is green See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/572/ for more details.