검증 실패 또는 유효하지 않은 중복에 대한 REST HTTP 상태 코드

검증 실패 또는 유효하지 않은 중복에 대한 REST HTTP 상태 코드

---

REST 기반 API로 애플리케이션을 구축하고 있으며 각 요청에 대해 상태 코드를 지정하는 시점에 도달했습니다.

유효성 검사에 실패한 요청에 대해 어떤 상태 코드를 보내야하거나 요청이 내 데이터베이스에 중복을 추가하려는 위치에 보내야합니까?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html을 살펴 보았지만 어느 것도 옳지 않은 것 같습니다.

상태 코드를 보낼 때 일반적인 관행이 있습니까?

---

입력 유효성 검사 실패 : 400 잘못된 요청 + 선택적 설명. 이것은 " RESTful Web Services " 책에서 제안됩니다 . 이중 제출 : 409 충돌

---

2014 년 6 월 업데이트

관련 사양 은 RFC2616 이었습니다. 이는 400 (Bad Request)을 다음과 같이 좁게 사용했습니다.

잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다.

따라서 의미 오류에 부적절하다고 주장 되었을 수도 있습니다. 그러나 더 이상은 아닙니다. 2014 년 6 월부터 이전 RFC2616을 대체 하는 관련 표준 RFC 7231 은 400 (잘못된 요청)을 다음 과 같이 더 광범위하게 사용합니다.

서버는 클라이언트 오류로 인식되는 문제로 인해 요청을 처리 할 수 ​​없거나 처리하지 않을 것입니다.

---

• 유효성 검사 실패 : 403 금지됨 ( "서버가 요청을 이해했지만 처리를 거부하고 있습니다"). 대중의 의견과는 달리 RFC2616은 "403은 인증 실패만을위한 것"이 아니라 "403 : 원하는 것을 알고 있지만 그렇게하지 않을 것입니다"라고 말합니다. 이 조건은 인증 때문일 수도 있고 아닐 수도 있습니다.
• 중복 추가 시도 : 409 충돌 ( "자원의 현재 상태와의 충돌로 인해 요청을 완료 할 수 없습니다.")

응답 헤더 및 / 또는 본문 (예 : 사용자 정의 헤더- X-Status-Reason: Validation failed)에 더 자세한 설명을 제공해야합니다 .

---

상태 코드 422, "Unprocessable Entity"를 권장 합니다 .

11.2. 422 처리 할 수없는 엔티티

422 (Unprocessable Entity) 상태 코드는 서버가 요청 엔티티의 콘텐츠 유형을 이해하고 (따라서 415 (Unsupported Media Type) 상태 코드가 부적절 함) 요청 엔티티의 구문이 정확함 (따라서 400 (Bad Request) ) 상태 코드가 부적절 함) 포함 된 지침을 처리 할 수 ​​없습니다. 예를 들어, XML 요청 본문에 올바른 형식 (즉, 구문 적으로 올바른)이 포함되어 있지만 의미 상 잘못된 XML 명령이 포함 된 경우이 오류 조건이 발생할 수 있습니다.

---

200,300, 400, 500은 모두 매우 일반적입니다. 제네릭을 원한다면 400도 괜찮습니다.

422는 점점 더 많은 API에서 사용되며 Rails에서 즉시 사용됩니다.

API에 대해 어떤 상태 코드를 선택하더라도 누군가 동의하지 않을 것입니다. 하지만 '400 + 텍스트 상태'가 너무 일반적이라고 생각하기 때문에 422를 선호합니다. 또한 JSON 지원 파서를 활용하지 않습니다. 반대로 JSON 응답이있는 422는 매우 명시 적이며 많은 오류 정보를 전달할 수 있습니다.

JSON 응답에 대해 말하자면이 경우 Rails 오류 응답을 표준화하는 경향이 있습니다.

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

이 형식은 양식 유효성 검사에 적합하며 '오류보고 풍부함'측면에서 지원해야 할 가장 복잡한 경우라고 생각합니다. 오류 구조가 이와 같으면 오류보고 요구를 모두 처리 할 수 ​​있습니다.

---

데이터베이스의 중복은 409 CONFLICT.

422 UNPROCESSABLE ENTITY유효성 검사 오류에 사용 하는 것이 좋습니다 .

여기에 4xx 코드에 대한 더 긴 설명이 있습니다. http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

---

200

으 ... (309, 400, 403, 409, 415, 422) ... 성공한 HTTP 요청에 대해 가장 좋은 반환 코드가 무엇인지 추측, 주장 및 표준화하려는 많은 답변이 있지만 REST 호출 이 실패했습니다 .

HTTP 상태 코드와 REST 상태 코드를 혼합하는 것은 잘못 되었습니다.

그러나 나는 많은 구현이 그것들을 혼합하는 것을 보았고 많은 개발자들이 나에게 동의하지 않을 수 있습니다.

HTTP return codes are related to the HTTP Request itself. A REST call is done using a Hypertext Transfer Protocol request and it works at a lower level than invoked REST method itself. REST is a concept/approach, and its output is a business/logical result, while HTTP result code is a transport one.

For example, returning "404 Not found" when you call /users/ is confuse, because it may mean:

• URI is wrong (HTTP)
• No users are found (REST)

"403 Forbidden/Access Denied" may mean:

• Special permission needed. Browsers can handle it by asking the user/password. (HTTP)
• Wrong access permissions configured on the server. (HTTP)
• You need to be authenticated (REST)

And the list may continue with '500 Server error" (an Apache/Nginx HTTP thrown error or a business constraint error in REST) or other HTTP errors etc...

From the code, it's hard to understand what was the failure reason, a HTTP (transport) failure or a REST (logical) failure.

If the HTTP request physically was performed successfully it should always return 200 code, regardless is the record(s) found or not. Because URI resource is found and was handled by the HTTP server. Yes, it may return an empty set. Is it possible to receive an empty web-page with 200 as HTTP result, right?

Instead of this you may return 200 HTTP code with some options:

• "error" object in JSON result if something goes wrong
• Empty JSON array/object if no record found
• A bool result/success flag in combination with previous options for a better handling.

Also, some internet providers may intercept your requests and return you a 404 HTTP code. This does not means that your data are not found, but it's something wrong at transport level.

From Wiki:

In July 2004, the UK telecom provider BT Group deployed the Cleanfeed content blocking system, which returns a 404 error to any request for content identified as potentially illegal by the Internet Watch Foundation. Other ISPs return a HTTP 403 "forbidden" error in the same circumstances. The practice of employing fake 404 errors as a means to conceal censorship has also been reported in Thailand and Tunisia. In Tunisia, where censorship was severe before the 2011 revolution, people became aware of the nature of the fake 404 errors and created an imaginary character named "Ammar 404" who represents "the invisible censor".

Why not simply answer with something like this?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google always returns 200 as status code in their Geocoding API, even if the request logically fails: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook always return 200 for successful HTTP requests, even if REST request fails: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

It's simple, HTTP status codes are for HTTP requests. REST API is Your, define Your status codes.

---

Ember-Data's ActiveRecord adapter expects 422 UNPROCESSABLE ENTITY to be returned from server. So, if you're client is written in Ember.js you should use 422. Only then DS.Errors will be populated with returned errors. You can of course change 422 to any other code in your adapter.

---

Status Code 304 Not Modified would also make an acceptable response to a duplicate request. This is similar to processing a header of If-None-Match using an entity tag.

In my opinion, @Piskvor's answer is the more obvious choice to what I perceive is the intent of the original question, but I have an alternative that is also relevant.

If you want to treat a duplicate request as a warning or notification rather than as an error, a response status code of 304 Not Modified and Content-Location header identifying the existing resource would be just as valid. When the intent is merely to ensure that a resource exists, a duplicate request would not be an error but a confirmation. The request is not wrong, but is simply redundant, and the client can refer to the existing resource.

In other words, the request is good, but since the resource already exists, the server does not need to perform any further processing.

참고URL : https://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate