'요청 한도 도달'에 대한 제안 된 HTTP REST 상태 코드

REST 서비스에 대한 사양을 작성하고 있는데,이 중 일부는 서비스 전체와 그룹 전체 또는 개별 리소스에 대한 사용자 조절 기능을 통합합니다. 마찬가지로 리소스 / 그룹 / 서비스별로 시간 제한을 구성 할 수 있습니다.

방금 HTTP 1.1 사양을 살펴보고 요청이 한계에 도달하여 요청이 이행되지 않을 것이라고 클라이언트와 통신하는 방법을 결정하려고합니다.

처음에는 클라이언트 코드 403 - Forbidden가 사양에서 나온 것임을 알았습니다 .

승인이 도움이되지 않으며 요청을 반복해서는 안됩니다

나를 귀찮게했다.

헤더를 503 - Service Unavailable사용하여 재시도 시간을 전달할 수 있기 때문에 실제로 사용하는 것이 더 좋습니다 Retry-After.

앞으로 전자 상거래를 통해 더 많은 요청을 '구매'할 수 있을지도 모릅니다 (이 경우 클라이언트 코드 402 - Payment Required가 완료된 경우 좋을 것입니다 !). 그러나 이것이 503 응답으로 똑같이 압착 될 수 있다고 생각합니다.

어느 쪽을 사용해야한다고 생각하십니까? 아니면 내가 고려하지 않은 또 다른 것이 있습니까?

429 너무 많은 요청

사용자가 주어진 시간에 너무 많은 요청을 보냈습니다. 속도 제한 체계와 함께 사용합니다. 이 코드는 RFC 6585 추가 HTTP 상태 코드 에서 승인되었습니다 .

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

어느 정도까지, 당신은 코드로 원하는 것을 자유롭게 할 수 있지만, 나는 당신이 물건을 깨뜨리고 있다고 불평 할 수있는 사람없이 사용할 수 503있거나 원하는 경우 사용할 수 있다는 데 동의합니다 402.

편집 : 순수 주의자는 503으로 시작하고 지불이 가능하면 전환해야한다고 말할 수 있습니다.

주석에서 이것에 대한 훌륭한 추가 :

4xx는 클라이언트가 특정 작업을 수행하여 해결할 수있는 오류를 나타내며 5xx는 클라이언트가 해결할 수없는 서버의 문제를 나타냅니다. 따라서 귀하의 경우 (1) 서버가 정확하게 동작하고 (ii) 클라이언트가 크레딧을 늦추거나 구매하여 오류를 "수정"할 수 있기 때문에 4xx가 더 적합합니다. 정확한 해상도는 429 응답 본문에 표시 될 수 있습니다. – Mike Chamberlain 7 시간 전