400 BAD 요청 HTTP 오류 코드 의미?


346

HTTP URL에 게시하는 JSON 요청이 있습니다.

이은으로 처리해야 400어디 requestedResource필드가 존재하지만 "Roman"이 필드에 대한 잘못된 값인가?

[{requestedResource:"Roman"}] 

필드가 존재하지 않는 400곳 으로 취급해야합니까 "blah"?

[{blah:"Roman"}]

34
어쩌면 402 , 그들이 정말로 가치를 보내려면 Roman, 그들은 당신에게 더 많은 돈을 지불해야합니다 :)
Jason Sperske

내가 본 실제 시나리오-데이터를 추가하기 위해 PUT 호출을 수행했습니다. 나는 동일한 요청 본문을 사용하여 다시 전화를 걸었고 이전 요청이 이미 처리되고 있다고 말하는 400을 얻었습니다. Google 시스템에서 해당 데이터를 추가하는 데 시간이 걸리는 것은 정상입니다.
MasterJoe2

답변:


361

400은 요청이 잘못되었음을 의미합니다. 즉, 클라이언트가 서버로 보낸 데이터 스트림은 규칙을 따르지 않았습니다.

JSON 페이로드가있는 REST API의 경우 일반적으로 400은 서비스의 API 사양에 따라 어떤 방식 으로든 JSON이 유효하지 않음을 나타내는 데 사용됩니다.

이 논리에 따라 제공 한 두 시나리오는 모두 400이어야합니다.

대신 이것이 JSON이 아니라 XML이라고 상상해보십시오. 두 경우 모두 XML은 정의되지 않은 요소 또는 부적절한 요소 값으로 인해 스키마 유효성 검사를 통과하지 않습니다. 그것은 나쁜 요청이 될 것입니다. 여기서도 마찬가지입니다.


3
"논리적으로 제공 한 두 시나리오는 모두 400이어야합니다."에 동의합니다. JSON의 내용이 여기에 중요하다고 생각하지 않습니다. 형식이 잘못되었다고 말하면 보내는 데이터 형식으로 문제를 해결한다고 믿습니다. 예를 들어 JSON에서 필드를 건너 뛰면 400이 표시됩니다.
Geethanga

2
restapitutorial.com/httpstatuscodes.html적절한 REST 응답 코드 세트가 있습니다. 또한 406 (Not Acceptable) 또는 405 method not allowed와 같은 유효한 요청을 처리하려는 방법에 따라 달라질 수 있습니다. 그러나 "잘못된 구문 때문에 서버가 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다."
Andrew Scott Evans

3
따라서 "잘못된 형식의 구문으로 인해 서버에서 요청을 이해할 수 없습니다"요청 (예 : 잘못된 HTTP 헤더 중 하나) 또는 요청에 의해 전달 된 데이터 (예 : JSON 값 누락) 중 하나 일 수 있습니다. ?
MC 황제

2
Vidya는 "XML은 절대 스키마 유효성 검사를 통과하지 못할 것"이라고 말합니다. XML 파서는 잘 구성된 문서 (구문 론적으로 건전한 문서)와 유효한 문서 (예 : 스키마에 따라 의미 론적으로 건전한 문서)를 구분합니다. 400 코드에 대한 설명은 "잘못된 구문 으로 인해 서버에서 요청을 이해할 수 없습니다 "이므로 유효성 검사 오류에 사용해서는 안됩니다 (imho).
Martin Lie

@Vidya stackoverflow.com/questions/42851301/… 이 오류를 살펴보십시오. 저를 도와 주시면이 오류와 비슷한 문제에 직면 해 있습니다
Mohan Gopi

74

에서 w3.org

10.4.1 400 잘못된 요청

잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다.


10
오류 400을 반환하는 정확성은 필드 대 값이 아니라 요청 전체를 기반으로합니다. 제 생각에는 HTTP 400이 좋은 방법이라고 생각합니다
Jason Sperske

요청에 URL, 헤더, 본문 등과 같은 것이 본문뿐만 아니라 잘못 될 수 있음을 클라이언트에게 알리기 위해 400 응답을 사용한다는 의미입니까?
MasterJoe2

3
URL의 경우 올바른 코드는 404입니다. 헤더의 경우, 던지기 일 것입니다. 헤더가 ID를 거부하면 403 (금지 된)이 올바른 방법처럼 보이지만 헤더가 출력 형식을 결정하면 어떻게됩니까? 내가 400에 맞다고 생각하는 유일한 길은 이해가되지 않고 반복해서는 안되는 행동이 요청되는 상황에있다. 나는 4 년 전에이 답변을 썼다. 요즘에는 오류조차 200을 반환해야한다고 생각하며 오류는 페이로드가 아닌 http 전송에만 적용되어야합니다.
Jason Sperske 21

1
이 답변은 아직까지 모든 차트를 읽지는 않았지만 stackoverflow.com/a/34324179/16959
Jason Sperske

@JasonSperske로드 밸런서, 프록시 및 기타 미들웨어는 종종 상태 코드를 사용하여 라우팅,보고 및 복구를 돕습니다. 운 좋게도 "422"와 같은 코드는 명시 적으로 페이로드에 관한 것이므로 페이로드 상태 코드에 대한 사양에는 약간의 여유가 있습니다.
Erik Aronesty

53

HTTP 응답 코드를 선택하는 것은 매우 쉬운 작업이며 간단한 규칙으로 설명 할 수 있습니다. 종종 잊혀지는 까다로운 부분은 RFC 7231의 6.5 절입니다.

HEAD 요청에 응답 할 때를 제외하고, 서버는 오류 상황에 대한 설명과 일시적 또는 영구 조건인지를 나타내는 표현을 보내야합니다.

규칙은 다음과 같습니다.

  1. 요청이 성공하면 2xx 코드 (리디렉션을위한 3xx)를 반환하십시오. 서버에 내부 논리 오류가 있으면 5xx를 리턴하십시오. 클라이언트 요청에 문제가 있으면 4xx 코드를 반환하십시오.
  2. 선택한 카테고리에서 사용 가능한 응답 코드를 살펴보십시오. 그들 중 하나가 당신의 상황에 잘 맞는 이름을 가지고 있다면 그것을 사용할 수 있습니다. 그렇지 않으면 x00 코드 (200, 400, 500)로 대체됩니다. 의심스러운 경우 x00 코드로 대체하십시오.
  3. 응답 본문에 오류 설명을 반환합니다. 4xx 코드의 경우 클라이언트 개발자가 이유를 이해하고 클라이언트를 수정하기에 충분한 정보를 포함해야합니다. 보안상의 이유로 5xx의 경우 세부 정보를 공개하지 않아도됩니다.
  4. 클라이언트가 다른 오류를 구별하고 이에 따라 다른 반응이 필요한 경우, 기계가 읽을 수 있고 확장 가능한 오류 형식을 정의하여 API의 모든 곳에서 사용하십시오. 처음부터 시작하는 것이 좋습니다.
  5. 클라이언트 개발자는 이상한 일을하고 사람이 읽을 수있는 설명으로 반환되는 문자열을 구문 분석하려고 시도 할 수 있습니다. 그리고 문자열을 변경하면 잘못 작성된 클라이언트를 깰 수 있습니다. 따라서 항상 기계가 읽을 수있는 설명을 제공하고 텍스트로 추가 정보를보고하지 않도록하십시오.

따라서 귀하의 경우에는 사용자 입력에서 "로마"가 얻어지고 클라이언트가 특정 반응을 가져야하는 경우 400 오류 및 이와 같은 것을 반환했습니다.

{
    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" is not supported"
}

또는 개발자가 잘못한 경우가 아니라면 클라이언트에서 잘못된 로직 오류이고 예상되지 않는 경우 일반적인 오류 :

{
    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}

21

두 경우 모두 "구문이 잘못되었습니다". 의미론이 잘못되었습니다. 따라서 IMHO a 400은 부적절합니다. 대신, 200과 같은 에러 객체와 같은 것을 반환하는 것이 적절할 것 { "error": { "message": "Unknown request keyword" } }입니다.

클라이언트 처리 경로를 고려하십시오. 구문 오류 (예 : 유효하지 않은 JSON)는 프로그램의 논리, 즉 일종의 버그이며 403과 비슷한 방식으로 처리되어야합니다. 다시 말해서, 나쁜 일이 잘못되었습니다.

반면에 매개 변수 값의 오류는 의미가 잘못되어 사용자 입력의 유효성이 잘못되었다는 의미 일 수 있습니다. HTTP 오류가 아닙니다 (422 일 수 있다고 생각하지만). 처리 경로가 다를 수 있습니다.

예를 들어, jQuery에서는 500과 일부 앱 고유 의미 론적 오류를 모두 처리하는 단일 오류 처리기를 작성하지 않아도됩니다. 다른 프레임 워크 인 Ember는 400 및 500과 같은 HTTP 오류를 큰 팻 오류와 동일하게 처리하므로 프로그래머는 "실제"오류인지 여부에 따라 진행 및 분기를 감지해야합니다.


4
+1, HTTP 의 P프로토콜을 나타내며 응답이 HTTP 오류 인 경우 저수준 문제 여야합니다. torazaburo가 설명 한 접근 방식을 사용하여 수년 동안 많은 코드 복잡성을 피했습니다. HTTP 오류로 인해 자주 발생하는 대신 탄력적 인 코드를 작성하면 REST 랜드에 통증이 줄어 듭니다 .
Dem Pilafian

25
200은 요청이 처리되었음을 의미하므로 정상적인 성공 논리는 클라이언트에서 실행되어야합니다. 여기에 분명히 오류가 있으므로 응답에 2xx 또는 3xx 코드를 사용할 수 없습니다. 서버 측 오류이고 클라이언트 측에 오류가 있기 때문에 5xx 일 수 없습니다. 따라서 4xx 오류 여야합니다. 그러나 응답 본문의 오류 설명은 올바른 작업이며 실제로 HTTP 사양에서 권장하는 방법입니다.
Alexey Guseynov

422 로거, 프록시 및 기타 도구에 대한 더 나은
에릭 Aronesty

16

요청 이 잘못 400되었음을 나타내는 것 이외의 다른 목적으로 상태 코드를 사용 하는 것은 명백한 잘못입니다.

요청 페이로드에 application/json(서버가 해당 데이터 형식을 예상하는 경우) 구문 분석 할 수없는 바이트 순서가 포함 된 경우 적절한 상태 코드는 415다음과 같습니다.

요청의 엔티티가 요청 된 메소드에 대해 요청 된 자원이 지원하지 않는 형식이므로 서버가 요청 서비스를 거부합니다.

요청 페이로드가 구문 상 정확하지만 의미 상 올바르지 않은 경우 비표준 422응답 코드 또는 표준 403상태 코드 가 사용될 수 있습니다 .

서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.


3
아니, 415 엔티티가 잘못된 유형의 예의 주장 때입니다 image/gif대신 text/json 에서 Content-Type:헤더입니다. -멀티 파트의 구성 요소에 잘못된 유형이 지정된 경우에도 적용 가능합니다. tools.ietf.org/html/rfc4918 에서 자세한 설명을 위해 422를 설명합니다.
Jasen

8

기대에 대해 생각하십시오.

클라이언트 응용 프로그램 인 경우 서버 쪽에서 문제가 발생했는지 알고 있어야합니다. 서버 blah가 누락되었거나 requestedResource오류가 400 오류보다 잘못된 경우 오류를 발생시켜야하는 경우 적절합니다.


5

보완 적으로, 내 것과 같은 문제를 겪을 수있는 사람들을 위해 $.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); 
    }
});

어쨌든, 다른 사람들이 설명했듯이, 오류는 서버가 요청의 형식이 잘못된 구문을 인식하지 못했기 때문에 실제로 인스턴스를 올리는 것입니다. 누군가에게 도움이되기를 바랍니다.


4

먼저 URL이 틀릴 수 있는지 확인하고, 올바른 경우 보내는 요청 본문을 확인하십시오. 가능한 원인은 보내는 요청에 올바른 구문이 없기 때문입니다.

자세히 설명하려면 요청 문자열에서 특수 문자를 확인하십시오. 그것이 사용되는 경우 (특별 문자)이 오류의 근본 원인입니다.

요청을 복사하고 각각의 모든 태그 데이터를 분석하십시오.


http 400 오류가 발생했습니다. 요청에 특수 문자가 있는지 확인했습니다. 이를 해결하기 위해 콘텐츠 유형에 charset = UTF-8을 전달했습니다.
Kislay Kishore
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.