REST - 자동 증가 리소스 식별자를 PUT 요청이 처리하는 방법

Question

HTTP 1.1에 따라. 사양 : 요청-URI 기존 리소스를 가리 키지 않으며 URI는 상기 요청 사용자 에이전트에 의하여 새로운 자원으로서 정의 될 수있는 것이 있으면

는 원 서버가 가지는 자원을 생성 할 URI.

즉 PUT을 사용하여 & 업데이트를 만들 수 있습니다. 더 구체적으로 말하면, PUT 요청을하면

PUT /users/1 

해당 사용자가 없기 때문에이 요청으로 인해이 ID를 가진 사용자를 생성 할 것으로 기대됩니다. 백엔드가 자동 증가 키를 사용하는 경우 어떻게 작동합니까? 가능하다면 (예 : 자동 증분 값이 6이고 요청 횟수가 10) & 가능한 경우 (예 : 요청 7) 가능하지 않은 경우 무시하는 것일까?

위에서 추출한 스 니펫에서이 유연성을 제공하는 것처럼 보입니다. 단지 설명을 찾는 것입니다.

Answer 1

자동 증가 키에 POST 대신 PUT을 사용하거나 리소스 ID에 자동 증가 키를 사용하지 않는 것이 좋습니다.

POST를 사용하는 경우 /users/1이 아닌 /users으로 게시됩니다. 답장은 /users/1 또는 ID가 무엇이든 리디렉션 할 수 있습니다.

PUT을 사용하는 경우 /users/10292829으로 PUT 할 수 있습니다. 여기서 번호는 클라이언트에서 생성 된 고유 한 리소스 키입니다. 이 키는 시간 생성이 가능하거나 시간, 세션 ID 및 클라이언트 청중 전체의 가치의 고유성을 보장하는 기타 요인의 해시 일 수 있습니다. 그런 다음 서버는 10292829 또는 다른 것과는 다른 자체 증가 색인을 생성 할 수 있습니다.

이에 대한 자세한 내용은 PUT vs POST in REST

---

가 다음을 참조하십시오. . .

/users/XXXXXXX에 PUT을 허용하는 경우 모든 사용자가 동일한 리소스를 참조하는 두 개의 고유 한 고유 키로 끝납니다. (10292829 및 1은 동일한 사용자를 나타낼 수 있음). REST 스타일 URL에서 이러한 각기 다른 키를 사용하는 방법을 결정해야합니다. 이 두 개의 별개 ID의 사용을 조정해야하기 때문에 첫 번째 옵션 인 /users에 게시하고 응답에서 생성 된 리소스의 고유 한 REST URL을 얻는 것을 선호합니다.

난 그냥 the relevant section of RFC 2616을 다시 읽고, 특히 REST 애플리케이션이 위해 설계된 리턴 코드 보았다 : 새로운 자원이

을 만든

10.2.2 (201) 요청이 충족되었습니다 및 결과 창조되고있다. 새로 생성 된 자원은 응답의 엔티티에서 반환 된 URI로 참조 될 수 있으며, 위치 헤더 필드에 의해 주어진 자원에 대해 가장 특정한 URI를가집니다. 응답에는 사용자 또는 사용자 에이전트가 가장 적합한 자원 특성 및 위치를 선택할 수있는 자원 특성 및 위치 목록을 포함하는 엔티티가 포함되어야합니다 (SHOULD). 엔티티 형식은 Content-Type 헤더 필드에 지정된 미디어 유형으로 지정됩니다.오리진 서버는 201 상태 코드를 리턴하기 전에 자원을 작성해야합니다 (MUST). 작업을 즉시 수행 할 수없는 경우 서버는 대신 202 (허용) 응답으로 응답해야합니다 (SHOULD).

그래서, 갈 수있는 편안하고 방법은 /users에 게시하고 /users/1를 지정하는 Location: 헤더와 더불어, 201 Created을 반환하는 것입니다.

Answer 2

POST를 사용하여 자원을 작성해야하며 PUT은 업데이트 용으로 사용해야합니다. 사실 REST 의미론은 그렇게하도록 강요합니다.