"계획 한계 초과"응답에 대한 권장 HTTP 상태 코드

사용자가 항상 여러 "계획"중 하나에있는 프로젝트를 위해 REST API를 설계하고 있습니다. 각 계획은 계정에 보유 할 수있는 최대 사용자 수 또는 업로드 할 수있는 최대 데이터 수와 같은 일부 리소스 제한을 정의합니다. 이러한 제한 중 하나에 도달하면 사용자는 계획을 업그레이드 (필수적으로 지불)하여 더 많은 리소스를 얻을 수 있습니다.

계정 리소스 제한으로 인해 작업을 수행 할 수없는 상황을 나타내는 특수한 상태 코드를 반환하고 계획을 업그레이드하면 문제가 해결됩니다 (예 : 사용자가 스토리지 용량의 100 %를 사용하고 추가 파일을 업로드하려는 경우) 이 응답을받습니다.

후보자는 IMHO :

• 403 Forbidden 그러나이 사례와 사용자 에게이 작업을 수행 할 수있는 권한이없는 경우를 구별하고 싶습니다.

• 401 Unauthorized -좋은 생각이 아닙니다. 인증 관련 문제에 사용하고 있습니다.

• 402 Payment Required -말이 되겠지만 비표준이지만 예약 된 상태 코드를 사용하는 것이 걱정됩니다.

• 423 Locked앞으로는 다른 어떤 용도로도 사용하지 않을 것 같은 표준보다 낮은 것

또 다른 옵션은 403응답 본문에 오류의 세부 사항을 나타내는 것과 같은 매우 표준적인 것을 사용하는 것입니다.

(a) 장기적으로 가장 잘 작동하고 (b) RESTful 원칙에 더 잘 부합 할 것이라고 생각하는 방법이 궁금합니다.

나는 403이 유일한 합리적인 응답이라고 생각하지만 405 Method Not Allowed 또는 409 Conflict가 수용 가능할 수도 있지만 403만큼 좋지 않다고 생각합니다.

서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다. 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하기를 원한다면 엔티티에서 거부 이유를 설명해야합니다.

403 오류를 반환하면 리소스가 거부 된 이유에 대한 정보가 포함됩니다. 유효하지 않은 권한은 가장 일반적인 경우 일 뿐이며, 한도를 크게 초과하지는 않습니다. 한도를 초과했기 때문에 권한이 없습니다.

403은 리소스에 액세스하지 못하는 상황을위한 것이며 403은 액세스 할 수있는 방법이 없기 때문에 403이 잘못되었다고 생각합니다. 고객에게는 분명히 액세스 할 수있는 방법이 있습니다. 지불.

401은 인증에 사용하고있을뿐 아니라 그 목적을 가지고 있기 때문에 실제로 잘못되었습니다.

API를 작성 중이므로 다른 사람이 API를 사용하는 코드를 작성해야하며 해당 사용자가 API 스펙을 읽어야한다고 가정합니다. 429 "너무 많은 요청"이있을 수 있습니다. 일반적으로 속도 제한 (예 : 클라이언트가 하루에 100 건의 요청을 할 수 있음)을 목적으로하지만 상황에 합리적으로 적용됩니다. 402 (결제 필요)도 허용됩니다. 사람들이 API를 사용하기 위해 사용할 도구에 따라 다릅니다. 429는 영리한 도구가 분 / 시간 / 일당 더 적은 수의 요청을 보내려고하지만 성공하지 못할 위험이 있습니다.

BTW https://tools.ietf.org/html/rfc6585 에 따르면 429 오류에는 문제의 성격을 설명하는 html 메시지가 포함되어야하므로 사용자가 제공하면 문제가 무엇인지 실제로 알 수 있습니다. 귀하의 답변에 해당 정보.

WebDAV는이를 위해 HTTP 507 Insufficient Storage 를 사용 하며 다른 종류의 스토리지 제한과 구별하기 위해 요청 본문에서 초과 된 할당량에 대한 추가 오류 코드를 포함합니다 .