내 HTTP 상태 코드를 구성해야합니까? (la Twitter 420 : 진정 향상)

저는 현재 처음으로 HTTP API를 구현하고 있습니다.

올바른 상황에 적합한 코드를 구현하기로 결정했기 때문에 Wikipedia 페이지에서 HTTP 상태 코드를 보는 데 많은 시간을 소비했습니다. 이 페이지에는 번호 420의 코드가 있는데,이 코드는 Twitter가 속도 제한에 사용하는 사용자 지정 코드입니다.

그러나 속도 제한에 대한 코드는 이미 있습니다. 429입니다.

이로 인해 이미 유스 케이스가있을 때 왜 사용자 정의를 설정 해야하는지 궁금해졌습니다. 그게 귀여워요? 그렇다면 어떤 상황에서 다른 상태 코드를 반환하는 것이 좋으며 클라이언트가 문제가있는 경우 어떻게해야합니까?

모질라가 농담 418: I’m a teapot응답을 구현하지 않는 곳에서 클라이언트가 어떤 상태 코드를 구현할지 선택한다고 생각합니다. 그것이 사실이라면, 트위터의 재미 있고 침착 한 코드가 문제가된다는 것을 상상할 수 있습니다.

내가 잘못 생각하지 않는 한, 우리가 원하는 것을 의미하기 위해 모든 코드 번호를 적절하게 할 수 있으며, 그 규칙에 따르면 404는 찾을 수 없으며 429는 쉽게 사용할 수 있습니다.

인터넷 전체는 컨벤션을 기반으로합니다. 우리는 그들을 RFC라고 부릅니다. RFC를 위반하면 아무도 귀하를 찾아가 체포하지 않지만 귀하의 서비스가 다른 지역과 상호 운용되지 않을 위험이 있습니다. 그리고 그러한 일 이 발생하면 스타트 업이 고객을 얻지 못하거나, 비즈니스가 악영향을 받거나, 주주가 반란을 일으키거나, 영구적으로 해고되는 등의 위험에 처하게됩니다.

HTTP 상태 코드에는 고유 한 IANA 레지스트리가 있으며, 각각은이를 정의한 RFC (또는 하나의 경우 ID)로 다시 추적 할 수 있습니다.

트위터의 이상한 420 상태 코드 대 RFC 6585에 정의 된 표준 429 상태 코드의 특별한 경우에 , 가장 최근의 설명은 후자가 최근에 정의 된 것입니다. RFC는 2012 년 4 월로 거슬러 올라갑니다. Twitter 는 이전에 사용되지 않는 API 1 버전에서만 420을 사용 합니다. 현재 API 버전 1.1은 실제로 429 상태 코드를 사용합니다 . 트위터가이를 위해 상태 코드를 필요로하고 자체적으로 정의한 것이 분명하다. 일단 표준이 사용 가능 해지면 표준으로 전환했습니다.

물론 모범 사례는 가능한 한 표준을 준수하는 것입니다. RFC를 읽을 때 거의 항상 "MUST"및 "SHOULD"와 같은 단어를 찾을 수 있습니다. 이는 RFC 2119 에서 찾을 수있는 애플리케이션을 빌드 할 때 특정 의미를 갖습니다 .

이 질문 은 문제를 조금 탐구합니다. 그러나 기술적으로 원하는 상태 코드를 만들 수는 있지만 기존의 상태 코드 의미 범위를 벗어나는 상태 코드를 만들면 API가 다른 사용자에게 더 모호하고 화려하게됩니다. 그것이 요점이 아니라면, 만들고있는 API가 너무 놀랍기 때문에 모든 사람들이 당신의 리드를 따르기 위해 코딩을 기꺼이 바꿀 것입니다.

이것은 다음과 같이 요약됩니다. 모든 표준이 깨질 수 있습니다. 그러나 당신이 그것을 깨 뜨리면 그렇게함으로써 무엇을 얻거나 잃습니까?

일반적으로 다른 작업을 수행 할 수 있지만 표준이 표준을 암시하는 경우, 확립 된 표준에서 벗어나야하는 매우 강력하고 강력한 이유가없는 한 표준을 준수하는 것이 가장 좋습니다. 트위터의 경우, 420: Enhance Your Calm그들은 자신이 직면 한 독특한 상황에 대해 명확하게 말하는 응답 코드를 만들고 있습니다. 서비스를 거부하지 않고 요청 속도가 느려집니다.