PUT응답 본문에 아무것도 반환하지 않는 RESTful 연산 에 대한 사람들의 의견이 궁금 합니다.
답변
HTTP 스펙 ( RFC 2616 )에는 적용 가능한 여러 권장 사항이 있습니다. 내 해석은 다음과 같습니다.
200 OK기존 자원 업데이트의 성공적인 PUT에 대한 HTTP 상태 코드 응답 본문이 필요하지 않습니다. ( 섹션 9.6에 따라204 No Content더 적절합니다.)201 Created새 자원의 성공적인 PUT에 대한 HTTP 상태 코드 ( 위치 헤더 필드에 리턴 된 새 자원에 대한 가장 구체적인 URI 및 응답 본문에 에코 된 자원의 기타 관련 URI 및 메타 데이터) ( RFC 2616 섹션 10.2.2 )- HTTP 상태 코드
409 Conflict인해 3에 실패하는 PUT에 대한 번째의 시도 갱신 및 응답 본문에서 현재 자원 사이의 차이점 목록과 함께, -party 수정. ( RFC 2616 섹션 10.4.10 ) 400 Bad Request응답 본문에 PUT이 실패한 이유를 설명하는 자연어 텍스트 (예 : 영어)가있는 실패한 PUT의 HTTP 상태 코드 입니다. ( RFC 2616 섹션 10.4 )
답변
여기서 대부분의 답변과 달리 실제로 PUT은 HTTP 코드 외에도 업데이트 된 리소스를 반환해야한다고 생각합니다.
PUT 조작에 대한 응답으로 자원을 리턴하려는 이유는 서버에 자원 표시를 보낼 때 서버가이 자원에 일부 처리를 적용 할 수 있기 때문에 클라이언트가이 자원을 어떻게 사용하는지 알고 싶어하기 때문입니다. 요청이 성공적으로 완료된 후 (그렇지 않으면 다른 GET 요청을 발행해야합니다).
답변
서버가 PUT에 응답하여 내용을 반환하는 것이 가능하다고 생각합니다. 사이드로드 된 데이터 (예 : ember-data에서 소비 한 형식)를 허용하는 응답 엔벨로프 형식을 사용하는 경우 데이터베이스 트리거 등을 통해 수정되었을 수있는 다른 오브젝트도 포함 할 수 있습니다 (사이드로드 된 데이터는 명시 적으로 줄입니다) 요청 수에 따라 최적화하기에 좋은 위치 인 것 같습니다.)
PUT 만 수락하고 다시보고 할 내용이 없으면 본문없이 상태 코드 204를 사용합니다. 보고 할 것이 있으면 상태 코드 200을 사용하고 본문을 포함합니다.
답변
HTTP / 1.1 사양 (섹션 9.6)을 적절한 응답 / 오류 코드를 설명한다. 그러나 응답 내용은 다루지 않습니다.
당신은 무엇을 기대합니까? 간단한 HTTP 응답 코드 (200 등)는 간단하고 모호하지 않습니다.
답변
REST API의 백엔드가 SQL 관계형 데이터베이스 인 경우
- 업데이트 할 수있는 모든 레코드에 RowVersion 이 있어야합니다 ( 업데이트 손실 문제 를 피하기 위해 )
- PUT 뒤에 항상 새 레코드 사본 을 리턴 해야 합니다 (새 RowVersion 을 얻기 위해 ).
업데이트 손실에 신경 쓰지 않거나 PUT 직후 클라이언트가 GET을 수행하도록하려는 경우 PUT에서 아무것도 반환하지 마십시오.
답변
클라이언트가 새로 작성된 자원을 찾을 수있는 위치를 가리키는 “Location”헤더와 함께 “Created”에 대한 HTTP 응답 코드 201.
답변
내 서비스에 RESTful API를 사용했으며 여기에 의견이 있습니다. 먼저 공통된 견해를 가져야합니다 PUT.
내가 가진 자원을 정의 : Stateless resource및 Stateful resource:
-
상태 비 저장 리소스 이러한 리소스의 경우 빈 본문으로 HttpCode를 반환하면 충분합니다.
-
상태 저장 리소스 예 : 리소스 버전. 이러한 종류의 리소스의 경우 버전을 변경하려는 경우 버전을 제공해야하므로 전체 리소스를 반환하거나 클라이언트에 버전을 반환하면 클라이언트가 업데이트 작업 후 가져 오기 요청을 보내지 않아도됩니다.
그러나 , 서비스 또는 시스템를 들어, 유지simple,clearly,easy to use and maintain가장 중요한 일이다.
