HTTP 프로토콜 반환 상태 코드 사양 문제

클라이언트가 서버에 요청을 보낸 후 데이터를 확인한 후 서버가 데이터와 일치하지 않음을 발견하고 오류를 반환해야 한다고 가정해 보겠습니다.

클라이언트의 요청 프로세스가 정확하므로 데이터 형식이 서버의 요구 사항을 충족하지 않더라도 서버는 200 상태 코드를 반환한 다음 오류 메시지나 일부 json 형식 보고서를 다시 가져와야 한다고 이해합니다. 메시지를 확인한 다음 실제 상태 코드를 메시지에 첨부합니다.

그런데 다른 사람들의 인터페이스를 살펴본 후 어떤 사람들은 510 상태 코드를 직접 반환했습니다.

실례합니다. 어떻게 생각하시나요? 표준은 무엇입니까?

답글 내용:

클라이언트가 서버에 요청을 보낸 후 데이터를 확인한 후 서버가 데이터와 일치하지 않음을 발견하고 오류를 반환해야 한다고 가정해 보겠습니다.

클라이언트의 요청 프로세스가 정확하므로 데이터 형식이 서버의 요구 사항을 충족하지 않더라도 서버는 200 상태 코드를 반환한 다음 오류 메시지나 일부 json 형식 보고서를 다시 가져와야 한다고 이해합니다. 메시지를 확인한 다음 실제 상태 코드를 메시지에 첨부합니다.

그런데 다른 사람들의 인터페이스를 살펴본 후 어떤 사람들은 510 상태 코드를 직접 반환했습니다.

실례합니다. 어떻게 생각하시나요? 표준은 무엇입니까?

인터넷의 많은 인터페이스는 대부분 비호환입니다. 직설적으로 말하면 HTTP 프로토콜을 이해하지 못하는 사람들이 작성한 HTTP 서비스이므로 참조할 가치가 없습니다. 그러니 그것에 대해 생각하지 마십시오. PHP가 해커들의 관심을 끄는 이유도 이와 유사합니다. 기꺼이 이 문제를 파헤쳐 주신 점에 대해 감사드립니다.

사실, 당신처럼 의욕이 넘치는 사람들에게 매우 적합한 "HTTP에 대한 최종 가이드"라는 책을 구입하는 것이 좋습니다.

사실 이 문제에 대한 귀하의 이해는 편향되어 있습니다.

요청 프로세스가 정확하다고 해서 응답이 200이어야 하는 것은 아닙니다. 응답을 받을 수 있다는 것은 요청 프로세스에 문제가 없다는 뜻입니다. 요청 프로세스가 잘못된 경우 DNS 예외나 연결 시간 초과 등이 발생합니다. 도착 코드도 볼 수 없습니다.

따라서 응답 코드는 요청에 대한 응답으로 HTTP 서버가 제공한 결과를 식별하는 데 사용됩니다.

이런 이유로 주로 2xx, 3xx, 4xx, 5xx로 나뉘는데, 2로 시작하는 것도 확실히 성공하고(단지 200도 아니고) 3으로 시작하는 것도 보통 예외는 아니지만. 302 리디렉션, 304 캐시가 만료되지 않음 등과 같이 요청에서 직접 리소스를 얻지 못했습니다.

핵심 사항은 다음과 같습니다. 4로 시작하는 숫자는 소위 제출된 데이터 형식이 400 또는 422로 잘못되었거나 어떤 이유로 인해 요청에 승인 401이 필요한 등 요청에 예외가 있음을 의미하는 경우가 많습니다(권한 부족). 또는 블랙리스트) 거부하려면 403을 사용하고, 요청한 데이터가 존재하지 않거나 현재 요청에서 데이터를 가져오고 싶지 않은 경우(매우 친숙함) 404를 사용하고, 요청 방법이 거부된 경우 405를 사용합니다. 예를 들어 다음을 사용해야 합니다. 데이터를 수정하려면 PUT, 데이터를 추가하려면 GET, 데이터를 삭제하려면 DELETE 요청을 사용하세요. 물론 일반적인 OPTIONS 및 HEAD 요청도 있습니다. 4로 시작하는 응답 코드가 가장 일반적입니다. 백과사전에서 HTTP 상태 코드에 대한 자세한 기사를 찾을 수 있습니다(어떤 백과사전이든 상관없음).

5로 시작하는 것은 주로 서버 오류입니다. 요청 오류로 인한 것이 아닌 예외는 500 Server Exception, 503 Server Unable to Provide Service 등 모두 5로 시작하는 상태 코드입니다.

HTTP 상태 코드는 일련의 RFC 표준 문서에 정의되어 있으므로 모든 인터페이스 프롬프트 세부 사항에 완전히 적응할 수는 없지만 대부분의 응답의 의미를 완전히 포괄할 수 있습니다. 세부 프롬프트의 경우 세부 문제에 대한 HTTP 상태 코드의 표현력 부족을 보완하기 위해 인터페이스 응답에 별도의 상태 응답 코드가 설정되는 경우가 많습니다. 예를 들어, 요청 형식이 잘못되었지만 특정 매개변수가 누락되었거나 너무 많은 매개변수가 제공되어 둘 다 400인 경우입니다. 클라이언트가 무슨 일이 일어났는지 명확히 알 수 있도록 하려면 인터페이스에서 이를 지원하기 위한 추가 항목을 정의해야 합니다. 이런 상황.

이 질문은 실제로 특정 적용 시나리오와 결합되어야 합니다.

먼저 클라이언트가 앱, 특히 모바일 앱을 참조하는 경우 200에 특정 오류 코드를 추가하는 것이 올바른 선택입니다! 이것은 더 이상 합리적이지는 않지만 중국(사실 외국도 있습니다)에는 HTTP 하이재킹이라는 국가적 조건이 있습니다. 404나 500은 운영자나 다른 사람이 직접 탈취할 수도 있습니다(웃음). 귀하가 반환하는 추가 http 오류 정보는 앱에서 수신되지 않습니다. 그래서 공장 A, 공장 B, 공장 T의 공용 네트워크 프로토콜을 보면 모두 이런 방식으로 오류를 전송하게 됩니다. 디자이너나 설계자가 Restful 및 HTTP 상태 코드가 무엇인지 이해하지 못하는 것은 아닙니다.

내부 프로토콜, 서비스 대 서비스, 환경이 보장된다면 표준적인 Restful 형식으로 오류를 정의할 수 있습니다.

오, 조건이 있고 표준 HTTP 상태 코드 형식의 오류 프로토콜을 선호한다면 사진을 공유하세요.

각 사양마다 이유가 있습니다. 언급하신 두 가지 상태 코드는 http 요청을 상태 코드 분석을 위한 주요 참조로 사용하는 것과, 다른 하나는 자체 인터페이스가 상태 코드를 분석하는 주요 참조로 사용된다는 것입니다. . 둘 다 나름의 이유가 있으며 사용 시나리오에 따라 다릅니다

표준화된 건가요? 아니면 회사의 지시를 따르세요~. 개인적으로는 오류를 반환하고 오류 메시지를 가져오는 데 http 상태 코드를 사용하는 것을 선호합니다.

틀렸습니다. 200 상태 코드는 아니지만 다른 상태 코드에도 해당 내용이나 json이 있을 수 있습니다. spring mvc를 사용해 본 적이 있는지 모르겠습니다. 이 함수는 확인에 사용되는 한 400 상태 코드와 json을 반환합니다.

이는 프로젝트가 어떻게 규제되는지에 따라 다릅니다! http 메소드를 따를 수도 있고 직접 설정할 수도 있습니다! 예를 들어, 이 오류 상태 코드를 받은 경우 새 상태 코드를 직접 설정한 다음 몇 가지 정보 프롬프트를 반환하세요!

필요에 따라 전체 프로젝트 사양이 우선합니다. 개인적으로 프로젝트를 주도하는 경우

Tencent의 WeChat 개발 문서를 참고하세요.
모두 통합된 인터페이스 반환 값입니다
http 상태 코드는 기본적으로 200입니다.
오류를 정의하려면 서로 다른 error_code를 사용하세요.

개인 의견

http 상태 코드를 사용하는 것이 맞습니다.

510 잘 모르겠어요. 제가 자주 쓰는 상태 코드를 알려주세요.

http 상태 400 및 403.

전자는 일반적으로 매개변수에 문제가 있기 때문에 요청을 구문 분석할 수 없음을 의미하며 대부분의 경우 이 오류는 판단을 위한 코드 작성이 필요하지 않으며 서버 프로그램이 자동으로 판단하고 이를 반환합니다. 상태.

예를 들어 내 매개변수는 1에서 10 사이의 숫자만 전달하도록 허용합니다. 사용자가 무작위로 전달하면 이 상태 코드가 반환됩니다.

후자는 사용자에게 액세스 권한이 없음을 의미합니다. 구성에 설정된 일부 금지된 액세스 경로 외에도 이 오류는 종종 권한을 확인하기 위한 코드를 작성해야 합니다.

예를 들어 내 백엔드는 특정 요청 헤더가 있는 특정 IP 및 컴퓨터에서만 액세스를 허용하고 다른 모든 컴퓨터는 이 상태 코드를 반환합니다.

---

200 json을 사용하여 상태 코드를 반환하는 경우 이러한 표준 http 상태 코드의 의미는 기본적으로 쓸모가 없습니다. 디자이너는 이미 이를 200과 404로만 단순화했습니다. 404도 json 상태 코드를 사용할 수 있으며, 연결 여부를 나타내기 위해 200을 사용하면 됩니다.

상태 코드의 이점은 무엇인가요?

최신 브라우저와 검색 엔진 크롤러는 http 상태 코드를 인식하고 부분적으로 처리합니다

예:

상태 코드 4xx는 현재 URL이 올바르지 않음을 의미하며, 요청을 다시 보내도 소용이 없습니다.
페이지 중 하나가 http 200 json 400을 반환하면 해당 매개변수에 문제가 있다는 의미입니다.

검색 엔진은 사용자 정의 상태 코드를 구문 분석하지 않으며 자연스럽게 이 데이터를 부정확하게 포함하게 됩니다.
일부 사용자는 검색 엔진을 통해 잘못된 매개변수가 있는 페이지로 이동합니다.

브라우저도 사용자 정의 상태 코드를 구문 분석하지 않습니다. 브라우저는 자동으로 액세스 기록을 기록하며 브라우저는 400, 403, 404와 같은 상태를 수신합니다. 검색 기록을 저장합니다(Chrome의 경우이고 다른 경우에도 비슷한 것 같습니다) .

200을 반환한 후에는 사용자가 URL 입력 시 브라우저 프롬프트 기록을 클릭하여 결과적으로 잘못된 연결에 다시 접속할 가능성이 높습니다.