Page Comparison

...

Journey-Planner-v3 is a national service for journey planning for all public transport in Norway. This service is used by many journey planners planner apps /webs or and other services and can be considered a part of the digital infrastructure for the Norwegian mobility sector. To ensure normal usage and stability of this service rate-limiting policies applies apply for all users. Users without an agreement with Entur will get the default policy and rate limit policies with partners of Entur will have a custom policy.

...

Other-request - One policy applies for all other request available in the graphQL GraphQL API.

Each policy is split into to elements:

Quota - the number of request pr. minute, calculated using a counter within a time window of one minute that starts at the first request after the previous time window has ended. E.g. given a quota policy of 10 requests per minute, a violation will occur if a request is sent after the counter has reached its limit of 10 requests within the current time window.

SpikeArrest - the number of request pr. second, calculated by keeping track of time elapsed since last request. E.g. a spike arrest policy of two requests per second, means a violation will occur if a request is sent within half a second after the previous request.

Policy levels

...

It is expected that consumers have control over their policy status with respect to traffic patterns. All responses from the service reply with a header value of headers containing current usage and remaining quota/spikearrest. When spike arrest occurs, headers are supplied containing the spike arrest policy itself. If your request hits the policy consumers violates one of the policies you will get a http 429 response.

Example SpikeArrest

(header name ?)response with status code 429 (https://datatracker.ietf.org/doc/html/rfc6585#section-4 ).

Example Spike arrest violation response headers (only given upon violation):

Spike-Allowed: 2
Spike-Range: per-second

Example Quota (header name ?)headers (all responses have these headers, except when there is a spike arrest violation):

Rate-Limit-Allowed: 30
Rate-Limit-Available: 29
Rate-Limit-Expiry-Time: Mon Jan 16 2023 12:17:34 GMT-0000 (UTC)
Rate-Limit-Range: "per-minute"
Rate-Limit-Used: 1

...

Re-try policy

It makes sense for consuming apps/webs clients to implement a conservative re-try policy on spike-arrest violations as spikes in traffic loads may occur.

Consuming apps/webs Clients should NOT implement a re-try policy for quota-violations as this only will make things worse for app/web users. Upon quota violation, clients should wait at least until Rate-Limit-Expiry-Time before trying again.