Page MenuHomeSoftware Heritage

Deprecate endpoints using an origin-id.
ClosedPublic

Authored by vlorentz on Jun 28 2019, 10:37 PM.

Details

Summary

Depends on D1666.

Test Plan

Install swh-storage with arc patch D1665 and run pytest.

Diff Detail

Repository
rDWAPPS Web applications
Branch
deprecate-origin-id
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 6581
Build 9177: tox-on-jenkinsJenkins
Build 9176: arc lint + arc unit

Event Timeline

vlorentz edited the summary of this revision. (Show Details)
vlorentz edited the test plan for this revision. (Show Details)

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.

What if I add endpoints so that each of the deprecated endpoints can be replaced with at most two API calls?

That's a middle-ground between this and too much extra combinatorics

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.

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)
This revision is now accepted and ready to land.Jul 2 2019, 11:05 AM
This revision was automatically updated to reflect the committed changes.