프론트엔드로서 최근 백엔드 작성을 시작했는데, 몇 가지 편안한 디자인 문제에 직면했습니다. 답변해 주시기 바랍니다.
안심 사양에서는 특히 HTTP Status Codes
의 사용을 강조하고 있는데, 사용하다 보면 의문이 듭니다. 특히 오류 정보 반환 영역에서요.
직접 사용할 때 'xxx 필드 누락'을 나타내는 20001 등 업무 관련 오류 코드 집합에 동의하고, 이를 http 응답 본문에 넣고 반환한 뒤 200 OK를 씁니다. 응답 헤더에 .
예를 들어 로그인 시 프런트 엔드에서 전달한 json에 비밀번호 필드가 없으면
400 Bad Request
HTTP 메시지를 반환하며 메시지 본문 부분은 다음과 같습니다( 예를 들어 모든 것을 단순하게 유지하세요 ):
<code>{ "code":20001, "message":"缺少password字段" }</code>
위 처리 방법에 대한 주요 질문은 다음과 같습니다.
가끔 비즈니스 오류가 발생하여 어떤 HTTP 상태 코드를 사용해야 할지 모르겠습니다. 예를 들어 새 사용자를 생성할 때 사용자 이름이 이미 존재하는 경우. , 그러면 I 이때 본문 부분은 작업하기 쉬운데 어떤 HTTP 상태 코드를 사용해야 합니까? 400 Bad Request
틀렸나봐요 프런트 엔드에서 보낸 정보는 괜찮습니다 401 Unauthorized
403 Forbidden
그리고 like는 여기서 사용할 수 없는데 이때 HTTP 상태 코드는 무엇을 사용해야 할까요?
실제로 많은 학생들은 상황에 관계없이 200 OK
를 반환한 다음 json을 사용하여 http body
에 오류 정보를 반환합니다. 부분이지만 저는 여전히 HTTP Status Codes
이 Restful의 매우 중요한 부분이라고 생각하고, Restful 사양에서도 그 사용을 강조하고 있으므로 이 부분을 어떻게 해야 하는지 모두가 조언해 주셨으면 좋겠습니다.
프론트엔드로서 최근 백엔드 작성을 시작했는데, 몇 가지 편안한 디자인 문제에 직면했습니다. 답변해 주시기 바랍니다.
안심 사양에서는 특히 HTTP Status Codes
의 사용을 강조하고 있는데, 사용하다 보면 의문이 듭니다. 특히 오류 정보 반환 영역에서요.
직접 사용할 때 'xxx 필드 누락'을 나타내는 20001 등 업무 관련 오류 코드 집합에 동의하고, 이를 http 응답 본문에 넣고 반환한 뒤 200 OK를 씁니다. 응답 헤더에 .
예를 들어 로그인 시 프런트 엔드에서 전달한 json에 비밀번호 필드가 없으면
400 Bad Request
HTTP 메시지를 반환하며 메시지 본문 부분은 다음과 같습니다( 예를 들어 모든 것을 단순하게 유지하세요 ):
<code>{ "code":20001, "message":"缺少password字段" }</code>
위 처리 방법에 대한 주요 질문은 다음과 같습니다.
가끔 비즈니스 오류가 발생하여 어떤 HTTP 상태 코드를 사용해야 할지 모르겠습니다. 예를 들어 새 사용자를 생성할 때 사용자 이름이 이미 존재하는 경우. , 그러면 I 이때 본문 부분은 작업하기 쉬운데 어떤 HTTP 상태 코드를 사용해야 합니까? 400 Bad Request
틀렸나봐요 프런트 엔드에서 보낸 정보는 괜찮습니다 401 Unauthorized
403 Forbidden
그리고 like는 여기서 사용할 수 없는데 이때 HTTP 상태 코드는 무엇을 사용해야 할까요?
실제로 많은 학생들은 상황에 관계없이 200 OK
를 반환한 다음 json을 사용하여 http body
에 오류 정보를 반환합니다. 부분이지만 저는 여전히 HTTP Status Codes
이 Restful의 매우 중요한 부분이라고 생각하고, Restful 사양에서도 그 사용을 강조하고 있으므로 이 부분을 어떻게 해야 하는지 모두가 조언해 주셨으면 좋겠습니다.
http 상태 코드 목록을 살펴보는 것이 좋습니다. 아직 4xx 응답 코드가 많이 있습니다. 일반적으로 4xx도 요청 오류를 나타냅니다.
사양은 일반적인 제안사항일 뿐입니다. 233 ok
잘 조율해서 관련 서류를 남겨두는 것이 관건입니다...
웹사이트 형태의 프로그램에서 사용한다고 가정하면, 웹페이지가 존재하지 않고 404를 반환하는 것은 사실이지만, 일반적으로 웹서버가 우리에게 이 기능을 해주지만 단순히 서버에서 제공하는 기본 페이지로는 충분하지 않습니다. 사람들이 볼 수 있는 웹사이트입니다. 사용자는 게임을 하더라도 계정을 구매하지 않습니다. 반환 코드로. 따라서 웹사이트의 경우 일반적으로 사용되는 반환 코드를 제공할 수 있지만 초점은 표시되는 페이지에 있습니다. 반환 코드가 400, 401 등인지 여부는 아무리 특별하더라도 오류 메시지 프롬프트 페이지만큼 간결하고 명확하지 않습니다.
API 유형 애플리케이션의 경우 API가 프런트엔드 Ajax용이라고 가정하면 비즈니스 로직이 잘못되었을 때 HTTP 프로토콜 상태 코드를 제공하면 콘솔 로그에만 오류가 인쇄됩니다. jquery로 처리된 ajax를 사용하는 경우 오류 함수 콜백이 발생하지만 이는 확실히 원하는 것이 아닙니다. 일반적인 접근 방식은 json 데이터를 반환하는 것입니다. json에 표시됩니다. 오류 발생 시 반환 코드를 사용하면 오류 콜백에서 구체적인 오류 원인을 얻을 수 없으며 xxx 작업에서 오류가 발생했다는 모호한 메시지만 표시할 수 있습니다. 이는 또한 고객 서비스의 어려움을 증가시키며, 사용자는 고객 서비스에 설명할 때 모호한 문제만 설명할 수 있습니다. 물론, 리버스 프록시를 사용한다고 가정하면 프런트엔드 프로그램은 현재 잘못된 반환 코드가 웹 애플리케이션에서 반환되는지, 리버스 프록시 서버에서 반환되는지를 구별할 수 없습니다.
순수 서버 간 API 간에 사용자 지정 HTTP 반환 코드를 사용한다고 가정하면 개발자가 HTTP 반환 코드를 구문 분석하는 것만으로는 충분하지 않다는 것을 알게 될 것입니다. json 데이터를 반환합니다. 물론 여기에도 위에서 언급한 역방향 프록시 문제가 여전히 존재합니다.
요약하자면, 사용자 정의 HTTP 반환 코드를 사용하는 것은 과학적이기는 하지만 너무 학술적이고 비실용적입니다. 특히 웹사이트 애플리케이션의 경우 링크를 찾을 수 없거나 잡히지 않는 예외가 발생하면 404 또는 500이 반환되며, 반환할 때 이를 전달하기 위해 친숙한 오류 페이지를 사용해야 합니다. 가능한.
422 처리할 수 없는 엔터티 - [POST/PUT/PATCH] 개체를 생성하는 동안 유효성 검사 오류가 발생했습니다.
적절하다고 느껴집니다
422 처리할 수 없는 엔터티 - [POST/PUT/PATCH] 개체를 생성하는 동안 유효성 검사 오류가 발생했습니다.
이 팁도 좋아요
정보가 상충되는 경우 409 Contribute를 이용하셔도 됩니다
여기에서 HTTP 상태 코드 분석을 확인할 수 있습니다
http://jingyan.baidu.com/arti...