클라이언트가 객체를 저장할 수있는 서버를 만들고 있습니다. 이러한 객체는 클라이언트 측에서 완전히 구성되며 객체의 전체 수명 동안 영구적 인 객체 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합니다.
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는 아닙니다.
