Should error 429 (TOO_MANY_REQUESTS) be mandatory in CAMARA specifications?

[rartych]

Problem description
The changes introduced in https://github.com/camaraproject/Commonalities/pull/329/files require to define Error status 429 TOO_MANY_REQUESTS in every API specification.

The purpose of it is mainly to inform about exceeded quota limits for given API Consumer.

Expected action
Verify the requirement - if this error status should be included in every specification.

Additional context
Error status 429 can be used also used by API platform to inform about overload conditions.
Discussed by TSC.

[Kevsy]

HI @rartych - I can't see a 429 discussion in that TSC minutes link, please can you check?

Error status 429 can be used also used by API platform to inform about overload conditions.

This seems to be not aligned with RFC6585 sections 4 and 7.2:

• Section 4 defines 429 as rate limiting per user, not for an overall (all-user) server overload.
• Section 7.2 warns that When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources. Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.

Rather, 503 Unavailable would seem to be the appropriate response to indicate server overload, and keep 429 for per-user rate limiting as defined in the standard.

[rartych]

@Kevsy Thank you for clarification.

I have prepared table comparing how Error 429 was defined in Fall24 meta-release: https://lf-camaraproject.atlassian.net/wiki/x/0gC_Aw

For Spring25 meta-release we need guidelines about removing GENERIC_429_QUOTA_EXCEEDED (as non mandatory) or keeping it according to API functionality.
#372 can also be addressed here.

Subprojects need to reshape error definitions to use enums anyway for the release preparation: https://lf-camaraproject.atlassian.net/wiki/x/AYC3Aw

[PedroDiez]

Our view on that is that 429 code can be documented as non-mandatory taking advantage of ongoing PR #374.

And let subprojects decide on whether this exception is relevant to be documented in API Spec.
Usually API GWs supports this feature in the same fashion as 5XX exceptions

[rartych]

Thank you @PedroDiez .
I have updated #374