Re: [httpapi] RateLimit ready for last call

[Roberto Polli <[e-mail]>]

Hi Darrel, Mark, Erik & co,

Replies inline.

Il giorno mar 19 lug 2022 alle ore 21:00 Darrel Miller
<[e-mail]> ha scritto:
> From a chair perspective I'd like to try and summarize where I think we are in this conversation.
Thanks!

> RateLimit-Policy is a new header that is defined as a SF List of Items where each item can have parameters.
Yes. Moreover there's one REQUIRED parameter.

> RateLimit-Remaining, RateLimit-Limit and RateLimit-Reset are equivalent to the existing x- versions of the headers that have significant industry usage.
> These header values are non-negative integer values that are simple for any consumer to parse.
Ok.

> The open question is whether the three existing headers should be replaced by a single:
>
> RateLimit: limit=10, remaining=5, reset=40
>
> The arguments for the new header include:
>
> - If we were designing this header from scratch and SF header support was widespread, it would be the preferred design.
I agree that this would be the "natural" design.
Since no one uses this approach, there is no operational experience
for saying that this design would be "preferable".

> - Header compression will produce a more efficient result
Since "remaining" and "reset" change on every response, the benefits of this
design wrt to compression are not clear to me yet.
IIUC the current design allows to at least compress RateLimit-Limit,
but header compression is not my field of competence.

> - Consistent use of SF parameters across both RateLimit-Policy and RateLimit header.
IMHO a single RateLimit field would be limited to the three dictionary
keys and no parameters.
This is a good point though and some times ago I tried to imagine how
a RateLimit SF could be extended with more keywords and parameters.
I foresaw then a fragmented landscape, while the actual text forces
server implementations to describe ratelimit in terms of actionable
quota units and time windows to simplify the life of clients.
Instead, servers might start adding parameters or dictionary keys with
the expectation that clients should
change their behavior according to them; this is something that we do not want.

> The arguments against the new  header include:
>
> - Many HTTP components and connectors do not yet natively support SF headers, making parsing this header more difficult
> - There is a concern that changing the existing headers into a single header will significantly impact adoption.
> - The original goal of the specification was to standardize existing industry behavior, with minor renames and non-breaking additions. The new header goes beyond that goal.
>
> Based on these arguments, I think the important question to ask ourselves is,  what is our primary goal?
> Is it to standardize existing industry behaviour to reduce further fragmentation,
The goal is with no doubt to reduce fragmentation standardizing an
existing industry behavior:
we didn't want to invent a new way of doing rate limiting.


> or is it to design a specification that describes where we want the industry to move to.
This might not be the right question: we all want the industry to move
towards SF.
In the Italian API Guidelines that apply to all Italian agencies
(~20.000 agencies including cities) we suggest using SF for custom
HTTP fields.

But the industry in *this specific case* might still prefer a single
combined field instead of three distinct fields even if SF were fully
supported.
To propose an alternative approach, we at HTTP API should probably
conduct a successful, large-scale, multi-stakeholder (SaaS,
on-premise/COTS) experiment with one single combined field.
I thought about it, and it would be great, but I realized that I do
not have the time/resources for that.

Sorry for the long answer - I tried to shorten it but without success.
Thanks for the opportunity to discuss such matters with you all, and
please forgive me if I can appear assertive: as a non-native speaker I
can miss some nuances sometimes.
I really acknowledge your deep and extensive expertise in this field
and appreciate
all the time you are spending on this spec.

Have a nice day,
R.