자원이 이미 존재하는 경우 POST에 대한 HTTP 응답 코드

클라이언트가 객체를 저장할 수있는 서버를 만들고 있습니다. 이러한 객체는 클라이언트 측에서 완전히 구성되며 객체의 전체 수명 동안 영구적 인 객체 ID로 완성됩니다.

클라이언트가 PUT을 사용하여 객체를 만들거나 수정할 수 있도록 API를 정의했습니다.

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{id}는 객체 ID이므로 Request-URI의 일부입니다.

이제 클라이언트가 POST를 사용하여 객체를 만들 수 있도록 고려하고 있습니다.

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

POST는 "추가"작업을 의미하기 때문에 객체가 이미있는 경우 어떻게 해야할지 모르겠습니다. 요청을 수정 요청으로 취급해야합니까, 아니면 어떤 오류 코드를 반환해야합니까?

내 감정이 409 Conflict가장 적절하지만 물론 야생에서는 거의 볼 수 없습니다.

자원의 현재 상태와 충돌하여 요청을 완료 할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 요청을 다시 제출할 수있는 상황에서만 허용됩니다. 응답 본문에는 사용자가 충돌의 원인을 인식 할 수있는 충분한 정보가 포함되어야합니다. 이상적으로, 응답 엔티티는 사용자 또는 사용자 에이전트가 문제를 해결하기에 충분한 정보를 포함 할 것이다. 그러나 불가능할 수도 있고 필요하지 않을 수도 있습니다.

PUT 요청에 대한 응답으로 충돌이 발생할 가능성이 높습니다. 예를 들어, 버전 관리를 사용 중이고 PUT중인 엔티티에 이전 (타사) 요청으로 작성된 자원과 충돌하는 자원에 대한 변경 사항이 포함 된 경우 서버는 409 응답을 사용하여 요청을 완료 할 수 없음을 표시 할 수 있습니다 . 이 경우 응답 엔티티는 응답 Content-Type에 의해 정의 된 형식으로 두 버전 간의 차이점 목록을 포함 할 수 있습니다.

따르면 RFC 7231 하는 303 참조 기타 사용될 수있는 후 처리 결과는 기존 자원의 표현에 해당 될 경우 .

개인적으로 WebDAV 확장 프로그램을 사용 422 Unprocessable Entity합니다.

RFC 4918에 따르면

422 Unprocessable Entity상태 코드는 서버가 요청 개체 (그러므로의 콘텐츠 유형을 이해하는 의미 415 Unsupported Media Type상태 코드 부적절), 상기 요청 엔티티의 구문 (따라서 올바른 400 Bad Request상태 코드 부적절) 그러나 포함 지시를 처리 할 수 없습니다.

그것은 모두 context 에 관한 것이며 요청의 서버 (클라이언트 또는 클라이언트 또는 둘 다)를 처리하는 담당자

서버 가 복제본을 가리키면 4xx를보십시오.

• 400 잘못된 요청-명백한 클라이언트 결함으로 인해 서버가 요청을 처리하지 않는 경우
• 409 충돌-서버가 요청을 처리하지 않지만 그 이유가 클라이언트의 결함이 아닌 경우
• ...

중복을 암시 적으로 처리 하려면 2XX를보십시오.

• 200 OK
• 201 만든
• ...

서버가 무언가를 리턴 할 것으로 예상되면 3XX를보십시오.

• 302 발견
• 303 다른 참조
• ...

서버가 기존 리소스를 가리킬 수 있으면 리디렉션을 의미합니다.

위의 방법으로 충분하지 않은 경우 항상 응답 본문에 오류 메시지를 준비하는 것이 좋습니다.

게임에 늦었을 수도 있지만 REST API를 만들려고 할 때이 시맨틱 문제를 발견했습니다.

Wrikken의 답변을 조금 확장하려면 상황에 따라 409 Conflict또는 403 Forbidden상황에 따라 사용할 수 있다고 생각합니다 . 즉, 사용자가 충돌을 해결하고 요청을 완료하기 위해 아무것도 할 수없는 경우 403 오류를 사용하십시오 (예 : DELETE명시 적으로 리소스를 제거하도록 요청하거나, 가능한 경우 409를 사용하십시오.

10.4.4 403 금지

서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다. 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하기를 원한다면, 엔티티에서 거절 이유를 설명해야한다. 서버가이 정보를 클라이언트가 사용할 수 없게하려면 상태 코드 404 (찾을 수 없음)를 대신 사용할 수 있습니다.

요즘 누군가가 "403"이라고 말하고 권한 또는 인증 문제가 떠오른다. 그러나 스펙은 기본적으로 서버가 클라이언트에게 요청하지 않을 것이라고 알리고 다시 묻지 말고 클라이언트가 '티.

PUTvs. POST...에 관해서 POST는 사용자가 리소스에 대한 식별자를 만들거나 수단을 만들지 않아야 할 때 리소스의 새 인스턴스를 만드는 데 사용해야합니다. PUT자원의 아이덴티티가 알려진 경우에 사용됩니다.

9.6 퍼트

...

POST와 PUT 요청의 근본적인 차이점은 Request-URI의 다른 의미에 반영됩니다. POST 요청의 URI는 동봉 된 엔터티를 처리 할 리소스를 식별합니다. 이 리소스는 데이터 수락 프로세스, 다른 프로토콜의 게이트웨이 또는 주석을 허용하는 별도의 엔티티 일 수 있습니다. 반대로 PUT 요청의 URI는 요청으로 둘러싸인 엔티티를 식별합니다. 사용자 에이전트는 의도 된 URI를 알고 있으며 서버는 요청을 다른 자원에 적용해서는 안됩니다. 서버가 요청을 다른 URI에 적용하기를 원하는 경우,

반드시 301 (영구적으로 이동) 응답을 보내야합니다. 그런 다음 사용자 에이전트는 요청을 리디렉션할지 여부에 대한 자체 결정을 내릴 수 있습니다.

"302 Found"가 논리적으로 들립니다. 그리고 RFC 2616는 이 GET 및 HEAD 이외의 요구에 대한 응답 (이 반드시 POST 포함) 될 수 있음을 말한다

그러나 여전히 RFC에 의해이 "발견 된"리소스를 얻기 위해 방문자가이 URL로 이동합니다. 실제 "발견 된"URL로 직접 이동하려면 "303 See Other"를 사용해야합니다. 그러나 다른 호출은 다음 URL을 GET으로 강제합니다. 좋은 점에서이 GET은 캐시 가능합니다.

나는 "303 See Other"를 사용할 것이라고 생각한다 . 본문에있는 "사물"로 응답 할 수 있는지 모르겠지만 서버에 한 번의 왕복을 저장하려고합니다.

업데이트 : RFC를 다시 읽은 후에도 존재하지 않는 "4XX + 303 Found"코드가 올바른 것으로 생각합니다. 그러나 "409 충돌"은 기존 자원을 가리키는 Location 헤더를 포함하여 (@Wrikken이 지적한) 최상의 기존 응답 코드 입니다.

나는 당신이 이것을해야한다고 생각하지 않습니다.

아시다시피 POST는 컬렉션을 수정하고 새 항목을 만드는 데 사용됩니다. 따라서 ID를 보내면 (좋은 생각이 아닌 것 같습니다) 컬렉션을 수정해야합니다. 즉, 항목을 수정해야하지만 혼란 스럽습니다.

ID없이 항목을 추가 할 때 사용하십시오. 모범 사례입니다.

PUT 요청에서와 같이 UNIQUE 제약 조건 (ID가 아닌)을 캡처하려는 경우 409로 응답 할 수 있습니다. 그러나 ID는 아닙니다.

나는 422 Unprocessable Entity요청이 유효하지 않지만 문제가 구문이나 인증에없는 경우에 사용됩니다.

다른 답변에 대한 논쟁으로, 4xx오류가 아닌 코드 를 사용 한다는 것은 클라이언트 오류가 아니라는 것을 의미합니다. 4xx오류 가 아닌 코드 를 사용하여 클라이언트 오류를 ​​나타내는 것은 전혀 의미가 없습니다.

것 같다 409 Conflict여기에서 가장 일반적인 대답 인 사양에 따르면 리소스가 이미 존재하고 적용하는 새 데이터가 현재 상태와 호환되지 않음을 의미합니다. 당신이 보내는 경우POST예를 들어 이미 생성 된 사용자 이름으로 요청하면 대상 리소스 (생성하려는 리소스)가 아직 게시되지 않았으므로 실제로 타겟 리소스와 충돌하지 않습니다. 저장된 리소스 버전과 요청 된 리소스 버전간에 충돌이있는 경우 특히 버전 제어에 오류가 발생합니다. 예를 들어 클라이언트가 이전 버전의 리소스를 캐시하고 더 이상 조건부로 유효하지 않은 잘못된 버전을 기반으로 요청을 보내는 경우와 같이 이러한 목적에 매우 유용합니다. "이 경우 응답 표현에는 수정 내역에 따라 차이를 병합하는 데 유용한 정보가 포함되어있을 것입니다." 해당 사용자 이름으로 다른 사용자를 작성하라는 요청은 처리 할 수 ​​없으며 버전 제어와 관련이 없습니다.

레코드의 경우 422는 이미 사용중인 이름으로 리포지토리를 만들 때 GitHub가 사용하는 상태 코드입니다.

REST에 대해서는 특정 시스템의 동작에 대한 결정을 내려야한다고 생각합니다.이 경우 "올바른"답변이 여기에 주어진 몇 가지 답변 중 하나라고 생각합니다. 클라이언트가 계속하기 전에 수정해야 할 실수를 한 것처럼 요청을 중지하고 동작하려면 409를 사용하십시오. 충돌이 실제로 중요하지 않고 요청을 계속 진행하려면 응답을 리디렉션하여 응답하십시오. 발견 된 엔티티에 대한 클라이언트. 적절한 REST API가 POST 이후에 해당 리소스의 GET 끝점으로 리디렉션 (또는 적어도 위치 헤더를 제공해야 함)해야한다고 생각 하므로이 동작은 일관된 경험을 제공합니다.

편집 : ID를 제공하기 때문에 PUT을 고려해야한다는 점도 주목할 가치가 있습니다. 그리고 나서 행동은 간단합니다. "지금 거기있는 것은 상관 없어요. 의미가 없다면 아무것도 만들어지지 않을 것입니다. 무언가가 있으면 교체됩니다. 서버가 해당 ID를 관리 할 때 POST가 더 적합하다고 생각합니다. 두 개념을 분리하면 기본적으로 그것을 다루는 방법을 알 수 있습니다 (즉, PUT은 dem 등원이므로 페이로드가 검증되고 POST가 항상 생성되므로 ID 충돌이 있으면 409가 충돌을 설명합니다) .

또 다른 잠재적 치료법은 PATCH를 사용하는 것입니다. PATCH는 내부 상태를 변경하는 것으로 정의되며 추가로 제한되지 않습니다.

PATCH는 기존 항목을 업데이트하여 문제를 해결합니다. 참조 : RFC 5789 : 패치

왜 202가 허용 되지 않습니까? OK 요청 (200s)이며 클라이언트 오류 (400s)는 없습니다.

에서 10 개 상태 코드 정의 :

"202 수락되었습니다. 처리 요청이 승인되었지만 처리가 완료되지 않았습니다."

... 이미 존재했기 때문에 완료 할 필요가 없기 때문에. 고객은 이미 존재한다는 것을 알지 못하고 잘못한 것이 없습니다.

202를 던지고 GET /{resource}/{id}이 반환 한 것과 비슷한 내용을 반환하려고합니다 .

중복 레코드의 올바른 코드를 확인하는 동안이 질문에 우연히 발견되었습니다.

내 무지를 용서하지만 모든 사람이 왜 "다중 선택"또는 "모호함"이라는 코드 "300"을 무시하는지 이해하지 못합니다.

내 생각에 이것은 비표준 또는 특정 시스템을 구축하기위한 완벽한 코드 일 것입니다. 나도 틀렸어!

https://tools.ietf.org/html/rfc7231#section-6.4.1

더 가능성이 높습니다 400 Bad Request

6.5.1. 400 잘못된 요청

400 (잘못된 요청) 상태 코드는 클라이언트 오류 (예 : 잘못된 요청 구문, 잘못된 요청 메시지 프레이밍 또는기만적인 요청 라우팅)로 인식되어 서버가 요청을 처리 할 수 ​​없거나 처리하지 않음을 나타냅니다.

요청에 중복 값 (이미 존재하는 값)이 포함되어 있으므로 클라이언트 오류로 인식 될 수 있습니다. 다음 시도 전에 요청을 변경해야합니다.
이러한 사실을 고려하여 HTTP STATUS 400 잘못된 요청으로 결론을 내릴 수 있습니다.

208- http : //httpstatusdogs.com/208-already-reported는 어떻습니까? 그게 옵션인가요?

내 의견으로는, 유일한 것이 반복 리소스라면 오류가 발생하지 않아야합니다. 결국, 클라이언트 측이나 서버 측 모두에 오류가 없습니다.