RESTful 'PUT'연산이 무언가를 반환해야하는 경우

437

PUT응답 본문에 아무것도 반환하지 않는 RESTful 연산 에 대한 사람들의 의견이 궁금 합니다.

— 어색한 코더
소스

615

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 )

— 시스템 일시 정지
소스

25

@stian 재미있는! PUT, DELETE 또는 다른 방법 의 사용을 특별히 배제하는 RFC 2616 (특히 10.2 Successful 2xx 및 10.2.1 200 OK ) 에서 아무것도 찾을 수 없기 때문에 모질라 측에서는 꽤 추측 할 만합니다200 . 내가 뭘 놓 쳤니? Mozilla가 W3와 IETF의 보스가되는 것과 같은? ;) 아니면 Postel의 견고성 원리에 대해 들어 본 적이 없습니다.

— 시스템 일시

52

@stian :이 문장은 2013 년 2 월 3 일에 삭제되었습니다. 누군가가 여기에 대해 읽었 기 때문일 수 있습니다. ;) developer.mozilla.org/en-US/docs/HTTP/…

— Christian Strempfer

6

PUT 방법의 의미는 리소스의 현재 상태를 무시하여 요청이 조건부 인 경우에만 타사 수정으로 인해 실패한 PUT에 대해 409 충돌을 반환하는 것입니다.

— Pedro Werneck

8

@systemPAUSE 좋은 답변입니다. 한 가지 작은 점 : 성공적인 응답으로 응답 본문을 반환하지 않으려면 204를 독점적으로 사용하는 것이 좋습니다. 일부 클라이언트 (예 : jQuery Ajax)는 길이가 0이 아닌 응답을 기대하지만 얻지 못하면 질식합니다. 이 질문에서 이것 의 예를 볼 수 있습니다 .

— nick_w

3

아마도 RFC2616은이 답변에 대한 이후 업데이트되었습니다. 9.6 No response body needed에서 200과 관련하여 언급 한 곳은 없다. 실제로 응답 본문은 PUT과 관련하여 전혀 언급되지 않았다. 그것은 단지 상태

If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

— 제임스

164

여기서 대부분의 답변과 달리 실제로 PUT은 HTTP 코드 외에도 업데이트 된 리소스를 반환해야한다고 생각합니다.

PUT 조작에 대한 응답으로 자원을 리턴하려는 이유는 서버에 자원 표시를 보낼 때 서버가이 자원에 일부 처리를 적용 할 수 있기 때문에 클라이언트가이 자원을 어떻게 사용하는지 알고 싶어하기 때문입니다. 요청이 성공적으로 완료된 후 (그렇지 않으면 다른 GET 요청을 발행해야합니다).

— LiorH
소스

3

"서버가이 리소스에 일부 처리를 적용 할 수도 있습니다." 정말 편안한가요?

— Raedwald

22

@Raedwald입니다. REST는 일반적으로 권장되지만 PUT 에서 전체 자원을 업데이트 할 필요는 없습니다 . 예를 들어, 생성 된 날짜 또는 마지막 수정 날짜와 같은 일부 필드는 PUT 본문에 포함되지 않아야하지만 PUT의 결과로 변경 될 수 있습니다. 그러나 PUT이 리소스를 반환해야한다는 LiorH에 동의하지 않습니다. 업데이트 된 리소스를 얻으려면 PUT 후에 GET이 필요합니다.

— Randolpho

19

@Randolpho REST는 PUT에서 전체 리소스를 업데이트하지 않아도 PATCH의 경우가 아니어야합니까?

— Marco Ciambrone

14

@MarcoCiambrone 예, 동의하며 이전 의견을 언급합니다. REST 및 PUT에서 조정을 변경했습니다 .PUT은 항상 dem 등원이어야하며 부분 업데이트에 사용해서는 안됩니다. PATCH가 지원되지 않는 한 POST가 유일한 대안입니다.이 경우 PATCH가 좋은 대안이 될 수 있습니다. 그러나 PATCH는 새로운 동사이며 일부 서버 측 프레임 워크에서 지원하지 않을 수 있습니다.

— Randolpho

2

답은 rfc7231 이전에 잘 작성되었지만 4.3.4 절에서 "PUT 메소드는 요청 자원 페이로드에 동봉 된 표현으로 정의 된 상태로 대상 자원의 상태를 작성하거나 대체하도록 요청합니다"

— aaaaaa

3

서버가 PUT에 응답하여 내용을 반환하는 것이 가능하다고 생각합니다. 사이드로드 된 데이터 (예 : ember-data에서 소비 한 형식)를 허용하는 응답 엔벨로프 형식을 사용하는 경우 데이터베이스 트리거 등을 통해 수정되었을 수있는 다른 오브젝트도 포함 할 수 있습니다 (사이드로드 된 데이터는 명시 적으로 줄입니다) 요청 수에 따라 최적화하기에 좋은 위치 인 것 같습니다.)

PUT 만 수락하고 다시보고 할 내용이 없으면 본문없이 상태 코드 204를 사용합니다. 보고 할 것이 있으면 상태 코드 200을 사용하고 본문을 포함합니다.

— unc 거리다
소스

2

HTTP / 1.1 사양 (섹션 9.6)을 적절한 응답 / 오류 코드를 설명한다. 그러나 응답 내용은 다루지 않습니다.

당신은 무엇을 기대합니까? 간단한 HTTP 응답 코드 (200 등)는 간단하고 모호하지 않습니다.

— 브라이언 아그 뉴
소스

예. 그러나 PUT 또는 POST 이후에 삽입 된 데이터가 db에 실제로 포함되는지 실제로 확인하려면 어떻게해야합니까? HTTP가 응답 본문을 다시 보낼 수 있으면 더 좋습니다.

— tnkh

1

@ tnkh 제안하는 것은 끔찍한 아이디어입니다. 업데이트를 성공적으로 마친 후 별도의 GET 전화를 걸어 원하는 것을 달성하십시오. 이 부서에서 문제가 발생하는 경우 성능을 보장하기 위해 캐싱 레이어가 도입됩니다. 우리는 '모든 것이 간다'는 일종의 논리를 어지럽히면서 이러한 문제를 해결할 수 없습니다. 2020 년에 상식이되어야 할 '단단한'기본 프로그래밍 원칙을 어지럽히 지 마십시오. 수치스러운 일입니다!

— XDS

@XDS 의견의 첫 부분을 인정합니다. 그러나 그 후 내 눈을 굴리는 것을 멈추지 못했습니다. 재미있는 코멘트

— tnkh

왜 재미 있다고 생각하는지 자세히 설명해 주셔서 감사합니다.

— XDS

2

REST API의 백엔드가 SQL 관계형 데이터베이스 인 경우

업데이트 할 수있는 모든 레코드에 RowVersion 이 있어야합니다 ( 업데이트 손실 문제 를 피하기 위해 )
PUT 뒤에 항상 새 레코드 사본 을 리턴 해야 합니다 (새 RowVersion 을 얻기 위해 ).

업데이트 손실에 신경 쓰지 않거나 PUT 직후 클라이언트가 GET을 수행하도록하려는 경우 PUT에서 아무것도 반환하지 마십시오.

— 존 헨켈
소스

1

클라이언트가 새로 작성된 자원을 찾을 수있는 위치를 가리키는 "Location"헤더와 함께 "Created"에 대한 HTTP 응답 코드 201.

— dc360
소스

5

PUT 객체는 새로 생성 된 리소스가 아니어야합니다.

— kdazzle

9

@kdazzle PUT은 확실히 새로 생성 된 리소스 일 수 있으며 종종있을 것입니다. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

— Charlie Schliesser

3

내 의견을 조금 더 잘 설명하기 위해. PUT은이 항목을이 특정 위치에 놓고 현재 존재하는 것을 대체합니다 (해당되는 경우).

— user1751825

3

바로 "현재있는 것을 바꾸는 것"이 핵심 문구입니다. 이미 존재하고 교체 중입니다. PUT은 새 자원을 작성하기위한 것이 아닙니다.

— Kevin M

3

@KevinM 최신 RFC 문서 rfc7231 에서와 같이 리소스를 만들 수 있다고 말합니다. "PUT 메서드는 대상 리소스의 상태를 만들 거나 바꾸 도록 요청합니다 ...] 그리고 PUT을 만들 수 없다고 생각하는 이유 새 리소스는 반드시 새 리소스의 위치를 알 필요가 없기 때문입니다. 그러나 위치 / 식별자를 알고 있다면 아직없는 경우 만들 수 있습니다 .

— 레오 레이

0

내 서비스에 RESTful API를 사용했으며 여기에 의견이 있습니다. 먼저 공통된 견해를 가져야합니다 PUT.

내가 가진 자원을 정의 : Stateless resource및 Stateful resource:

상태 비 저장 리소스 이러한 리소스의 경우 빈 본문으로 HttpCode를 반환하면 충분합니다.
상태 저장 리소스 예 : 리소스 버전. 이러한 종류의 리소스의 경우 버전을 변경하려는 경우 버전을 제공해야하므로 전체 리소스를 반환하거나 클라이언트에 버전을 반환하면 클라이언트가 업데이트 작업 후 가져 오기 요청을 보내지 않아도됩니다.

그러나 , 서비스 또는 시스템를 들어, 유지simple,clearly,easy to use and maintain가장 중요한 일이다.

— 브루스
소스

6

"PUT은 만들거나 가져 오지 않은 리소스를 업데이트하는 데 사용됩니다." -사실이 아니고 흔한 일이 아닙니다. 사양에 따라 PUT은 리소스를 만들 수 있습니다. Clear = 일반적으로 알려진 사양을 따릅니다.

— Imre Pühvel

-3

빈 요청 본문이 GET 요청의 원래 목적을 유지하고 빈 응답 본문이 PUT 요청의 원래 목적을 유지하는 것과 같습니다.

— AnthonyWJones
소스

-3

괜찮은 것 같습니다 ...하지만 성공 / 실패 / 시간 게시 / # 바이트 수신 / 등의 기초적인 표시라고 생각합니다. 바람직하다.

편집 : 나는 데이터 무결성 및 / 또는 기록 유지 라인을 생각하고 있었다; 수신 된 시간에 대한 MD5 해시 또는 타임 스탬프와 같은 메타 데이터는 큰 데이터 파일에 유용 할 수 있습니다.

— 제이슨 S
소스

1

상태 응답 헤더에서 200 OK는 어떻습니까? "고마워요?"라고 말할만큼 충분하다고 생각하십니까?

— AnthonyWJones

: 응답 헤더는 상태 코드를 포함하는 것이며, 그래 우리는이 시점에서 HTTP에 대해 얘기

— AwkwardCoder

-4

이상적으로는 성공 / 실패 응답을 반환합니다.

— cgp
소스

13

그러나 응답 본문에는 없습니다. HTTP 상태 코드가 그 장소입니다. 어쩌면 오류가있는 경우 응답에 입찰에 일부 확장 오류 정보가 반환 될 수 있습니다

— The Archetypal Paul

-4

HTTP 응답의 헤더와 본문에는 차이가 있습니다. PUT은 본문을 반환하지 않아야하지만 헤더에 응답 코드를 반환해야합니다. 성공하면 200을, 그렇지 않으면 4xx를 선택하십시오. 널 리턴 코드와 같은 것은 없습니다. 왜 이러고 싶니?

— 알렉산더
소스