HTTP URL에 게시하는 JSON 요청이 있습니다.
이은으로 처리해야 400
어디 requestedResource
필드가 존재하지만 "Roman"
이 필드에 대한 잘못된 값인가?
[{requestedResource:"Roman"}]
필드가 존재하지 않는 400
곳 으로 취급해야합니까 "blah"
?
[{blah:"Roman"}]
답변
400은 요청이 잘못되었음을 의미합니다. 즉, 클라이언트가 서버로 보낸 데이터 스트림은 규칙을 따르지 않았습니다.
JSON 페이로드가있는 REST API의 경우 일반적으로 400은 서비스의 API 사양에 따라 어떤 방식 으로든 JSON이 유효하지 않음을 나타내는 데 사용됩니다.
이 논리에 따라 제공 한 두 시나리오는 모두 400이어야합니다.
대신 이것이 JSON이 아니라 XML이라고 상상해보십시오. 두 경우 모두 XML은 정의되지 않은 요소 또는 부적절한 요소 값으로 인해 스키마 유효성 검사를 통과하지 않습니다. 그것은 나쁜 요청이 될 것입니다. 여기서도 마찬가지입니다.
답변
에서 w3.org
10.4.1 400 잘못된 요청
잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다.
답변
HTTP 응답 코드를 선택하는 것은 매우 쉬운 작업이며 간단한 규칙으로 설명 할 수 있습니다. 종종 잊혀지는 까다로운 부분은 RFC 7231의 6.5 절입니다.
HEAD 요청에 응답 할 때를 제외하고, 서버는 오류 상황에 대한 설명과 일시적 또는 영구 조건인지를 나타내는 표현을 보내야합니다.
규칙은 다음과 같습니다.
- 요청이 성공하면 2xx 코드 (리디렉션을위한 3xx)를 반환하십시오. 서버에 내부 논리 오류가 있으면 5xx를 리턴하십시오. 클라이언트 요청에 문제가 있으면 4xx 코드를 반환하십시오.
- 선택한 카테고리에서 사용 가능한 응답 코드를 살펴보십시오. 그들 중 하나가 당신의 상황에 잘 맞는 이름을 가지고 있다면 그것을 사용할 수 있습니다. 그렇지 않으면 x00 코드 (200, 400, 500)로 대체됩니다. 의심스러운 경우 x00 코드로 대체하십시오.
- 응답 본문에 오류 설명을 반환합니다. 4xx 코드의 경우 클라이언트 개발자가 이유를 이해하고 클라이언트를 수정하기에 충분한 정보를 포함해야합니다. 보안상의 이유로 5xx의 경우 세부 정보를 공개하지 않아도됩니다.
- 클라이언트가 다른 오류를 구별하고 이에 따라 다른 반응이 필요한 경우, 기계가 읽을 수 있고 확장 가능한 오류 형식을 정의하여 API의 모든 곳에서 사용하십시오. 처음부터 시작하는 것이 좋습니다.
- 클라이언트 개발자는 이상한 일을하고 사람이 읽을 수있는 설명으로 반환되는 문자열을 구문 분석하려고 시도 할 수 있습니다. 그리고 문자열을 변경하면 잘못 작성된 클라이언트를 깰 수 있습니다. 따라서 항상 기계가 읽을 수있는 설명을 제공하고 텍스트로 추가 정보를보고하지 않도록하십시오.
따라서 귀하의 경우에는 사용자 입력에서 “로마”가 얻어지고 클라이언트가 특정 반응을 가져야하는 경우 400 오류 및 이와 같은 것을 반환했습니다.
{
"error_type" : "unsupported_resource",
"error_description" : "\"Roman\" is not supported"
}
또는 개발자가 잘못한 경우가 아니라면 클라이언트에서 잘못된 로직 오류이고 예상되지 않는 경우 일반적인 오류 :
{
"error_type" : "malformed_json",
"error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}
답변
두 경우 모두 “구문이 잘못되었습니다”. 의미론이 잘못되었습니다. 따라서 IMHO a 400은 부적절합니다. 대신, 200과 같은 에러 객체와 같은 것을 반환하는 것이 적절할 것 { "error": { "message": "Unknown request keyword" } }
입니다.
클라이언트 처리 경로를 고려하십시오. 구문 오류 (예 : 유효하지 않은 JSON)는 프로그램의 논리, 즉 일종의 버그이며 403과 비슷한 방식으로 처리되어야합니다. 다시 말해서, 나쁜 일이 잘못되었습니다.
반면에 매개 변수 값의 오류는 의미가 잘못되어 사용자 입력의 유효성이 잘못되었다는 의미 일 수 있습니다. HTTP 오류가 아닙니다 (422 일 수 있다고 생각하지만). 처리 경로가 다를 수 있습니다.
예를 들어, jQuery에서는 500과 일부 앱 고유 의미 론적 오류를 모두 처리하는 단일 오류 처리기를 작성하지 않아도됩니다. 다른 프레임 워크 인 Ember는 400 및 500과 같은 HTTP 오류를 큰 팻 오류와 동일하게 처리하므로 프로그래머는 “실제”오류인지 여부에 따라 진행 및 분기를 감지해야합니다.
답변
요청 이 잘못 400
되었음을 나타내는 것 이외의 다른 목적으로 상태 코드를 사용 하는 것은 명백한 잘못입니다.
요청 페이로드에 application/json
(서버가 해당 데이터 형식을 예상하는 경우) 구문 분석 할 수없는 바이트 순서가 포함 된 경우 적절한 상태 코드는 415
다음과 같습니다.
요청의 엔티티가 요청 된 메소드에 대해 요청 된 자원이 지원하지 않는 형식이므로 서버가 요청 서비스를 거부합니다.
요청 페이로드가 구문 상 정확하지만 의미 상 올바르지 않은 경우 비표준 422
응답 코드 또는 표준 403
상태 코드 가 사용될 수 있습니다 .
서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.
답변
기대에 대해 생각하십시오.
클라이언트 응용 프로그램 인 경우 서버 쪽에서 문제가 발생했는지 알고 있어야합니다. 서버 blah
가 누락되었거나 requestedResource
오류가 400 오류보다 잘못된 경우 오류를 발생시켜야하는 경우 적절합니다.
답변
보완 적으로, 내 것과 같은 문제를 겪을 수있는 사람들을 위해 $.ajax
양식 데이터를 서버에 게시 하는 데 사용 하고 400
있으며 처음 에는 오류가 발생했습니다.
자바 스크립트 변수가 있다고 가정합니다.
var formData = {
"name":"Gearon",
"hobby":"Be different"
};
아래와 같이 변수 formData
를 키 값으로 직접 사용하지 마십시오 data
.
$.ajax({
type: "post",
dataType: "json",
url: "http://localhost/user/add",
contentType: "application/json",
data: formData,
success: function(data, textStatus){
alert("Data: " + data + "\nStatus: " + status);
}
});
대신 JSON.stringify를 사용하여 formData
아래와 같이 캡슐화하십시오 .
$.ajax({
type: "post",
dataType: "json",
url: "http://localhost/user/add",
contentType: "application/json",
data: JSON.stringify(formData),
success: function(data, textStatus){
alert("Data: " + data + "\nStatus: " + status);
}
});
어쨌든, 다른 사람들이 설명했듯이, 오류는 서버가 요청의 형식이 잘못된 구문을 인식하지 못했기 때문에 실제로 인스턴스를 올리는 것입니다. 누군가에게 도움이되기를 바랍니다.