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?
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:
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?