Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope discussions follow up #119

Open
baywet opened this issue Oct 17, 2022 · 0 comments
Open

Scope discussions follow up #119

baywet opened this issue Oct 17, 2022 · 0 comments

Comments

@baywet
Copy link

baywet commented Oct 17, 2022

Hi everyone 馃憢,
I'm following up regarding the scope discussions for this spec.
The original repo having been archived, the issue that's linked in the FAQ is locked.
And I wasn't able to find a recent follow up besides #10

Having a standardized scope header (or span if you want to avoid the confusion with OAuth) would be interesting for clients of large APIs.
Large APIs (or reverse proxy APIs) often implement multiple rate limiting mechanisms and logics for sets of endpoints. (e.g. all the endpoints managing users will have a different way of tracking consumption from endpoints managing the users' files).

Since the client is talking to a single host, not having better precision about which calls should slow down/wait and which can keep going would mean multiple features are impacted by the same throttling policy. (e.g. if the files endpoint ask to slow down, depending on how the application is build, the profile feature might be impacted).

The memo was really interesting to solve for that problem. It'd be a nice addition to:

  • specify multiple values can be transmitted
  • specify it can also be in the trailers
  • specify the values might be glob patterns

Aside from this main suggestion, maybe the link to the issue in the FAQ should be update to an issue/discussion that's not locked?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Discussion
Development

No branches or pull requests

1 participant