HTTP에서 POST와 PUT의 차이점은 무엇입니까?

질문자 :alex

RFC 2616, § 9.5 에 따르면 POST 는 리소스 를 생성 하는 데 사용됩니다.

POST 메서드는 요청에 포함된 엔터티를 Request-Line의 Request-URI에 의해 식별된 리소스의 새 하위 항목으로 원본 서버가 수락하도록 요청하는 데 사용됩니다.

RFC 2616, § 9.6 에 따르면 PUT 는 리소스 를 생성하거나 교체 하는 데 사용됩니다.

PUT 메소드는 동봉된 엔티티가 제공된 Request-URI 아래에 저장되도록 요청합니다. Request-URI가 이미 존재하는 리소스를 참조하는 경우 동봉된 엔터티는 원본 서버에 있는 것의 수정된 버전으로 간주되어야 합니다(SHOULD). Request-URI가 기존 리소스를 가리키지 않고 해당 URI가 요청하는 사용자 에이전트에 의해 새 리소스로 정의될 수 있는 경우 원 서버는 해당 URI로 리소스를 생성할 수 있습니다.

그렇다면 리소스를 생성하기 위해 어떤 HTTP 메소드를 사용해야 할까요? 아니면 둘 다 지원해야 합니까?

답변자 : Brian R. Bondy

전반적인:

PUT과 POST 모두 생성에 사용할 수 있습니다.

무엇을 사용해야 하는지 구별하기 위해 "무엇에 대해 작업을 수행하고 있습니까?"라고 질문해야 합니다. 질문을 위한 API를 설계한다고 가정해 보겠습니다. POST를 사용하려면 질문 목록에 대해 수행합니다. PUT을 사용하려면 특정 질문에 대해 그렇게 할 것입니다.

좋습니다. 둘 다 사용할 수 있으므로 RESTful 디자인에서 어느 것을 사용해야 할까요?

PUT과 POST를 모두 지원할 필요는 없습니다.

어떤 것을 사용하는지는 귀하에게 달려 있습니다. 그러나 요청에서 참조하는 개체에 따라 올바른 것을 사용하는 것을 기억하십시오.

몇 가지 고려 사항:

• 생성한 URL 개체의 이름을 명시적으로 지정합니까, 아니면 서버가 결정하도록 합니까? 이름을 지정한 경우 PUT을 사용하십시오. 서버가 결정하도록 하면 POST를 사용합니다.
• PUT은 멱등성을 가정하도록 정의되어 있으므로 개체를 두 번 PUT하면 추가 효과가 없습니다. 이것은 좋은 속성이므로 가능하면 PUT을 사용합니다. PUT 멱등성이 실제로 서버에서 올바르게 구현되었는지 확인하십시오.
• 동일한 개체 URL을 사용하여 PUT을 사용하여 리소스를 업데이트하거나 생성할 수 있습니다.
• POST를 사용하면 URL을 수정하는 동시에 2개의 요청이 들어올 수 있으며 개체의 다른 부분을 업데이트할 수 있습니다.

예:

나는 이것에 관한 SO에 대한 또 다른 답변의 일부로 다음을 썼습니다.

우편:

리소스를 수정하고 업데이트하는 데 사용됩니다.

 POST /questions/<existing_question> HTTP/1.1 Host: www.example.com/

다음은 오류입니다.

 POST /questions/<new_question> HTTP/1.1 Host: www.example.com/

URL이 아직 생성되지 않은 경우 이름을 지정하는 동안 POST를 사용하여 생성해서는 안 됩니다. <new_question> 이 아직 존재하지 않기 때문에 '리소스를 찾을 수 없음' 오류가 발생해야 합니다. 먼저 서버에 <new_question> 리소스를 PUT해야 합니다.

POST를 사용하여 리소스를 생성하려면 다음과 같이 할 수 있습니다.

 POST /questions HTTP/1.1 Host: www.example.com/

이 경우 리소스 이름이 지정되지 않으면 새 개체 URL 경로가 반환됩니다.

놓다:

리소스를 생성하거나 덮어쓰는 데 사용됩니다. 리소스 새 URL을 지정하는 동안.

새 리소스의 경우:

 PUT /questions/<new_question> HTTP/1.1 Host: www.example.com/

기존 리소스를 덮어쓰려면:

 PUT /questions/<existing_question> HTTP/1.1 Host: www.example.com/

또한 RFC 7231 섹션 4.3.4 PUT 상태(강조 추가됨)를 좀 더 간결하게

4.3.4. 놓다

PUT 메서드는 대상 리소스의 상태가 created 되거나 요청 메시지 페이로드에 포함된 표현에 의해 정의된 상태 replaced

답변자 : Cheeso

웹에서 다음과 같은 주장을 찾을 수 있습니다.

• POST 는 리소스를 생성하는 데 사용되어야 하고 PUT 은 리소스를 수정하는 데 사용해야 합니다.
• PUT 은 리소스를 생성하는 데 사용해야 하고 POST 는 리소스를 수정하는 데 사용해야 합니다.

어느 쪽도 완전히 옳지 않습니다.

---

작업의 멱등성 을 기반으로 PUT과 POST 중에서 선택하는 것이 더 좋습니다.

PUT 은 리소스를 넣는 것을 의미합니다. 주어진 URL에서 사용할 수 있는 모든 것을 다른 것으로 완전히 대체합니다. 정의에 따르면 PUT는 멱등원입니다. 원하는 만큼 반복하면 결과는 동일합니다. x=5 는 멱등수입니다. 리소스가 이전에 존재하는지 여부에 관계없이 리소스를 PUT할 수 있습니다(예: 생성 또는 업데이트)!

POST 는 리소스를 업데이트하거나, 보조 리소스를 추가하거나, 변경을 유발합니다. x++ 가 멱등성이 아닌 방식으로 POST는 멱등성이 아닙니다.

---

이 인수에 의해 PUT은 생성할 사물의 URL을 알고 있을 때 생성하기 위한 것입니다. 생성하려는 항목의 범주에 대한 "공장" 또는 관리자의 URL을 알고 있는 경우 POST를 사용하여 생성할 수 있습니다.

그래서:

 POST /expense-report

또는:

 PUT /expense-report/10929

답변자 : Nigel Thorne

• URL에 대한 POST 는 서버 정의 URL에 하위 리소스를 생성합니다.
• URL에 대한 PUT 은 클라이언트가 정의한 URL에서 리소스 전체를 생성/대체합니다.
• URL에 대한 PATCH 는 해당 클라이언트가 정의한 URL에서 리소스의 일부 를 업데이트합니다.

PUT 및 POST에 대한 관련 사양은 RFC 2616 §9.5ff입니다.

POST는 자식 리소스를 생성 하므로 /items /items 리소스 아래에 있는 리소스를 생성합니다. 예. /items/1 . 동일한 포스트 패킷을 두 번 전송하면 두 개의 리소스가 생성됩니다.

PUT 은 클라이언트가 알고 있는 URL에서 리소스를 생성하거나 교체하기 위한 것입니다.

따라서 PUT 은 리소스가 생성되기 전에 클라이언트가 이미 URL을 알고 있는 CREATE의 후보일 뿐입니다. 예. /blogs/nigel/entry/when_to_use_post_vs_put 제목이 리소스 키로 사용됨

PUT 은 알려진 URL의 리소스가 이미 있는 경우 이를 대체하므로 동일한 요청을 두 번 보내도 효과가 없습니다. 즉, PUT에 대한 호출은 멱등적 입니다.

RFC는 다음과 같이 읽습니다.

POST 요청과 PUT 요청 간의 근본적인 차이점은 Request-URI의 다른 의미에 반영됩니다. POST 요청의 URI는 동봉된 엔터티를 처리할 리소스를 식별합니다. 해당 리소스는 데이터 수락 프로세스, 다른 프로토콜에 대한 게이트웨이 또는 주석을 수락하는 별도의 엔터티일 수 있습니다. 대조적으로, PUT 요청의 URI는 요청에 포함된 엔티티를 식별합니다. 사용자 에이전트는 URI가 무엇인지 알고 있으며 서버는 요청을 다른 리소스에 적용하려고 시도해서는 안 됩니다(MUST NOT). 서버가 요청이 다른 URI에 적용되기를 원하는 경우,

참고: PUT은 대부분 리소스를 업데이트하는 데 사용되었지만(전체 교체), 최근에는 PUT에서 전체 리소스를 교체하도록 지정하기 때문에 기존 리소스를 업데이트하기 위해 PATCH를 사용하려는 움직임이 있습니다. RFC 5789.

업데이트 2018 : PUT을 피하기 위해 만들 수 있는 경우가 있습니다. "PUT 없이 휴식" 참조

"REST without PUT" 기술은 소비자가 새로운 '통일화된' 요청 리소스를 게시해야 한다는 아이디어입니다. 앞에서 논의한 바와 같이 고객의 우편 주소를 변경하는 것은 우편 주소 필드 값이 다른 "고객" 자원의 PUT이 아니라 새로운 "ChangeOfAddress" 자원에 대한 POST입니다.

REST API 디자인에서 가져옴 - Thinkworks의 Prakash Subramaniam이 작성한 리소스 모델링

이렇게 하면 API가 단일 리소스를 업데이트하는 여러 클라이언트의 상태 전환 문제를 방지하고 이벤트 소싱 및 CQRS와 더 잘 일치하도록 합니다. 작업이 비동기적으로 완료되면 변환을 게시하고 적용되기를 기다리는 것이 적절해 보입니다.

답변자 : 7hi4g0

요약:

창조하다:

다음과 같은 방식으로 PUT 또는 POST로 수행할 수 있습니다.

놓다

은 / 자원 URI 또는 컬렉션 아래 식별자 newResourceId와 새로운 리소스를 생성한다.

 PUT /resources/<newResourceId> HTTP/1.1

우편

은 / 자원 URI, 또는 모음에서 새 자원을 작성합니다. 일반적으로 식별자는 서버에서 반환됩니다.

 POST /resources HTTP/1.1

업데이트:

다음과 같은 방식으로 PUT으로 만 수행할 수 있습니다.

놓다

/resources URI 또는 컬렉션 아래의 기존 ResourceId를 식별자로 사용하여 리소스를 업데이트합니다.

 PUT /resources/<existingResourceId> HTTP/1.1

설명:

REST 및 URI를 일반적으로 처리할 때 왼쪽에 일반 이 있고 오른쪽에 특정 이 있습니다 . 제네릭 은 일반적으로 컬렉션 이라고 하고 보다 구체적인 항목은 리소스 라고 할 수 있습니다. 리소스 에는 컬렉션 이 포함될 수 있습니다.

예:

<-- 일반 -- 특정 -->

 URI: website.com/users/john website.com - whole site users - collection of users john - item of the collection, or a resource URI:website.com/users/john/posts/23 website.com - whole site users - collection of users john - item of the collection, or a resource posts - collection of posts from john 23 - post from john with identifier 23, also a resource

POST를 사용할 때 항상 컬렉션을 참조하므로 다음과 같이 말할 때마다:

 POST /users HTTP/1.1

사용자 컬렉션에 새 사용자를 게시하고 있습니다.

계속해서 다음과 같이 시도하면:

 POST /users/john HTTP/1.1

작동하지만 의미상 사용자 컬렉션 아래의 john 컬렉션 에 리소스를 추가하고 싶다고 말하는 것입니다.

PUT을 사용하면 아마도 컬렉션 내부의 리소스 또는 단일 항목을 참조하게 됩니다. 그래서 당신이 말할 때 :

 PUT /users/john HTTP/1.1

서버 업데이트에 지시하거나 존재하지 않는 경우 사용자 컬렉션 아래에 john 리소스 를 생성합니다.

투기:

사양의 몇 가지 중요한 부분을 강조하겠습니다.

우편

POST 메서드는 요청에 포함된 엔터티를 Request-Line의 Request-URI에 의해 식별된 리소스 의 새 하위 항목으로 원본 서버가 수락 하도록 요청하는 데 사용됩니다.

따라서 컬렉션 에 새 리소스 를 만듭니다.

놓다

PUT 메소드는 동봉된 엔티티가 제공된 Request-URI 아래에 저장되도록 요청합니다. Request-URI가 이미 존재하는 리소스를 참조하는 경우 동봉된 엔터티는 원본 서버에 있는 것의 수정된 버전으로 간주되어야 합니다(SHOULD). Request-URI가 기존 리소스를 가리키지 않고 해당 URI가 요청하는 사용자 에이전트에 의해 새 리소스 로 정의될 수 있는 경우 원본 서버는 해당 URI로 리소스를 생성할 수 있습니다."

따라서 리소스의 존재를 기반으로 생성하거나 업데이트하십시오.

참조:

• HTTP/1.1 사양
• 위키피디아 - REST
• URI(Uniform Resource Identifier): 일반 구문 및 의미

답변자 : Alexander Torstling

POST 는 "여기에 사용자 생성을 위한 입력이 있습니다. 나를 위해 생성하십시오"와 같이 "새로 생성"을 의미합니다.

PUT 은 "여기에 사용자 5에 대한 데이터가 있습니다"와 같이 "이미 존재하는 경우 삽입, 대체"를 의미합니다.

사용자 URL 을 아직 모르기 때문에 example.com/users에 POST 합니다. 서버에서 URL을 생성하기를 원합니다.

특정 사용자를 교체/생성하고 싶기 때문에 example.com/users/id에 PUT

동일한 데이터로 두 번 게시한다는 것은 다른 ID를 가진 두 명의 동일한 사용자를 생성한다는 의미입니다. 동일한 데이터로 두 번 PUT하면 사용자가 먼저 생성되고 두 번째에는 동일한 상태로 업데이트됩니다(변경 사항 없음). PUT 몇 번 수행하든 결국 동일한 상태로 끝나기 때문에 매번 "동일하게 유력하다" - 멱등성(idempotent)이라고 합니다. 이는 자동으로 요청을 재시도하는 데 유용합니다. 브라우저에서 뒤로 버튼을 누를 때 더 이상 '재전송하시겠습니까?'라는 메시지가 표시되지 않습니다.

일반적인 조언은 URL 생성을 제어해야 할 때 POST 그렇지 않으면 PUT 사용하십시오. POST 보다 PUT 을 선호합니다.

답변자 : ThaDon

"실용적인" 조언을 추가하고 싶습니다. 저장하려는 개체를 검색할 수 있는 "id"를 알고 있는 경우 PUT을 사용합니다. 예를 들어 향후 조회 또는 업데이트를 수행하기 위해 데이터베이스 생성 ID를 반환해야 하는 경우 PUT을 사용하면 잘 작동하지 않습니다.

따라서: 기존 사용자 또는 클라이언트가 id를 생성하고 id가 고유한 것으로 확인된 사용자를 저장하려면:

 PUT /user/12345 HTTP/1.1 <-- create the user providing the id 12345 Host: mydomain.com GET /user/12345 HTTP/1.1 <-- return that user Host: mydomain.com

그렇지 않으면 POST를 사용하여 처음에 개체를 만들고 PUT을 사용하여 개체를 업데이트합니다.

 POST /user HTTP/1.1 <--- create the user, server returns 12345 Host: mydomain.com PUT /user/12345 HTTP/1.1 <--- update the user Host: mydomain.com

답변자 : Premraj

둘 다 클라이언트에서 서버로의 데이터 전송에 사용되지만 다음과 같은 미묘한 차이점이 있습니다.

놓다	우편
기존 리소스를 대체하거나 리소스가 없는 경우 생성합니다. www.example.com/com/customer/{customerId} www.example.com/com/customer/123/order/{orderId} 클라이언트가 식별자를 선택합니다.	새 리소스 및 하위 리소스 생성, 예를 들어 파일이 파일을 포함하는 디렉토리에 종속되거나 행이 데이터베이스 테이블에 종속됩니다. www.example.com/com/customer/ www.example.com/com/customer/123/order/ 서버에서 식별자를 반환함
멱등원, 즉 PUT 하면 효과가 없습니다. 예: 원하는 만큼 반복하면 결과는 동일합니다. x=1;	POST 는 안전하지도 멱등성도 아닙니다. 예: x++;
구체적으로 작동	추상적으로 작동
PUT 사용하여 리소스를 생성하거나 업데이트한 다음 동일한 호출을 다시 수행하는 경우 리소스는 여전히 존재하며 첫 번째 호출에서와 동일한 상태를 유지합니다.	두 개의 동일한 POST 요청을 수행하면 동일한 정보를 포함하는 두 개의 리소스가 생성될 가능성이 높습니다.

유추:

• 즉, 소요 시간 및이 어디에 넣어 PUT.
• 우체국 에서 우편물을 보낼 때 POST하십시오.

소셜 미디어/네트워크 비유:

• 포스트는 소셜 미디어에 : 우리가 메시지를 게시 할 때, 그것은 새 게시물을 작성합니다.
• 우리가 이미 게시한 메시지를 넣습니다(즉, 편집).

답변자 : Tim Sullivan

POST를 사용하여 생성하고 PUT을 사용하여 업데이트합니다. 어쨌든 Ruby on Rails가 그렇게 하고 있습니다.

 PUT /items/1 #=> update POST /items #=> create

답변자 : Jörg W Mittag

REST는 매우 높은 수준의 개념입니다. 사실, HTTP는 전혀 언급조차 하지 않습니다!

HTTP에서 REST를 구현하는 방법에 대해 의문점이 있으면 언제든지 AtomPub(Atom Publication Protocol) 사양을 살펴볼 수 있습니다. AtomPub은 REST의 발명가이자 HTTP의 (공) 발명가인 Roy Fielding의 일부 의견을 바탕으로 많은 HTTP 및 REST 전문가에 의해 개발된 HTTP로 RESTful 웹 서비스를 작성하기 위한 표준입니다.

실제로 AtomPub을 직접 사용할 수도 있습니다. 블로깅 커뮤니티에서 나왔지만 블로깅에만 국한되지 않습니다. HTTP를 통해 임의의(중첩된) 임의 리소스 컬렉션과 RESTfully 상호 작용하기 위한 일반 프로토콜입니다. 애플리케이션을 리소스의 중첩된 컬렉션으로 나타낼 수 있다면 AtomPub만 사용할 수 있으며 PUT 또는 POST를 사용할지 여부, 반환할 HTTP 상태 코드 및 모든 세부 정보에 대해 걱정할 필요가 없습니다.

리소스 생성(섹션 9.2)에 대한 AtomPub의 설명은 다음과 같습니다.

컬렉션에 구성원을 추가하기 위해 클라이언트는 컬렉션의 URI에 POST 요청을 보냅니다.

답변자 : Joshcodes

HTTP + REST API가 있는 서버에서 리소스를 생성하기 위해 PUT 또는 POST를 사용할지 여부는 URL 구조를 소유한 사람에 따라 결정됩니다. 클라이언트가 URL 구조를 알거나 정의에 참여하게 하는 것은 SOA에서 발생하는 바람직하지 않은 결합과 유사한 불필요한 결합입니다. 이스케이프 유형의 커플 링은 REST가 인기있는 이유입니다. 따라서 적절한 사용 방법은 POST입니다. 이 규칙에는 예외가 있으며 클라이언트가 배포하는 리소스의 위치 구조에 대한 제어를 유지하려고 할 때 발생합니다. 이것은 드물고 아마도 다른 문제가 있음을 의미합니다.

이 시점에서 일부 사람들은 RESTful-URL 이 사용되면 클라이언트가 리소스의 URL을 알고 있으므로 PUT이 허용된다고 주장할 것입니다. 결국 이것이 정규화되고 정규화된 Ruby on Rails, Django URL이 중요한 이유입니다. Twitter API를 보십시오. 그 사람들 은 Restful-URL 과 같은 것이 없으며 Roy Fielding 자신이 다음과 같이 말합니다 .

REST API는 고정 리소스 이름이나 계층 구조(클라이언트와 서버의 명백한 결합)를 정의해서는 안 됩니다. 서버는 자신의 네임스페이스를 자유롭게 제어할 수 있어야 합니다. 대신 서버가 미디어 유형 및 링크 관계 내에서 해당 지침을 정의하여 HTML 형식 및 URI 템플릿에서 수행되는 것과 같이 적절한 URI를 구성하는 방법에 대해 클라이언트에게 지시할 수 있도록 합니다. [여기서 실패는 클라이언트가 RPC의 기능적 결합에 해당하는 데이터 지향적인 도메인 특정 표준과 같은 대역 외 정보로 인해 리소스 구조를 가정하고 있음을 의미합니다.]

http://roy.gbiv.com/untangle/2008/rest-apis-must-be-hypertext-driven

RESTful-URL 의 아이디어는 서버가 URL 구조를 담당하고 결합을 피하기 위해 그것을 사용하는 방법을 자유롭게 결정할 수 있어야 하기 때문에 실제로 REST를 위반하는 것입니다. 이것이 혼란스럽다면 API 디자인에서 자기 발견의 중요성에 대해 읽게 됩니다.

POST를 사용하여 리소스를 생성하는 것은 POST가 멱등성이 아니기 때문에 디자인 고려 사항과 함께 제공됩니다. 즉, POST를 여러 번 반복해도 매번 동일한 동작이 보장되지는 않습니다. 이것은 사람들이 PUT을 사용하여 하지 말아야 할 리소스를 생성하는 것을 두려워합니다. 그들은 그것이 잘못되었다는 것을 알고 있지만(POST는 CREATE를 위한 것입니다) 그들은 이 문제를 해결하는 방법을 모르기 때문에 어쨌든 그렇게 합니다. 이러한 우려는 다음 상황에서 입증됩니다.

1. 클라이언트는 서버에 새 리소스를 게시합니다.
2. 서버는 요청을 처리하고 응답을 보냅니다.
3. 클라이언트는 응답을 받지 않습니다.
4. 서버는 클라이언트가 응답을 받지 못했다는 것을 인식하지 못합니다.
5. 클라이언트에는 리소스에 대한 URL이 없으므로(따라서 PUT은 옵션이 아님) POST를 반복합니다.
6. POST는 멱등성이 아니며 서버는 …

6단계는 사람들이 일반적으로 무엇을 해야 할지 혼란스러워하는 단계입니다. 그러나이 문제를 해결하기 위해 kludge를 만들 이유가 없습니다. 대신 HTTP는 RFC 2616에 지정된 대로 사용할 수 있으며 서버는 다음과 같이 응답합니다.

10.4.10 409 충돌

리소스의 현재 상태와 충돌하여 요청을 완료할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 요청을 다시 제출할 수 있을 것으로 예상되는 상황에서만 허용됩니다. 응답 본문에는 충분히 포함되어야 합니다(SHOULD).

사용자가 충돌의 원인을 인식할 수 있는 정보. 이상적으로 응답 엔터티에는 사용자 또는 사용자 에이전트가 문제를 해결하기에 충분한 정보가 포함됩니다. 그러나 이는 불가능할 수 있으며 필요하지 않습니다.

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

다음과 같은 이유로 상태 코드 409 Conflict로 응답하는 것이 올바른 방법입니다 .

• 시스템에 이미 있는 리소스와 일치하는 ID를 가진 데이터의 POST를 수행하는 것은 "리소스의 현재 상태와의 충돌"입니다.
• 중요한 부분은 클라이언트가 서버에 리소스가 있음을 이해하고 적절한 조치를 취하는 것입니다. 이는 "사용자가 충돌을 해결하고 요청을 다시 제출할 수 있을 것으로 예상되는 상황"입니다.
• 충돌하는 ID가 있는 리소스의 URL과 리소스에 대한 적절한 전제 조건이 포함된 응답은 RFC 2616에 따라 이상적인 경우인 "사용자 또는 사용자 에이전트가 문제를 해결할 수 있는 충분한 정보"를 제공합니다.

2616을 대체하기 위한 RFC 7231 릴리스 기반 업데이트

RFC 7231 은 2616을 대체하도록 설계되었으며 섹션 4.3.3 에서 POST에 대한 다음 가능한 응답을 설명합니다.

POST 처리 결과가 기존 리소스의 표현과 동일할 경우 원 서버는 위치 필드에 기존 리소스의 식별자와 함께 303(기타 참조) 응답을 전송하여 사용자 에이전트를 해당 리소스로 리디렉션할 수 있습니다(MAY). 이것은 사용자 에이전트에 리소스 식별자를 제공하고 공유 캐싱에 더 적합한 방법을 통해 표현을 전송하는 이점이 있지만 사용자 에이전트에 이미 캐시된 표현이 없는 경우 추가 요청 비용이 듭니다.

이제 POST가 반복되는 경우 단순히 303을 반환하고 싶을 수 있습니다. 그러나 그 반대가 사실입니다. 303을 반환하는 것은 여러 생성 요청(다른 리소스 생성)이 동일한 콘텐츠를 반환하는 경우에만 의미가 있습니다. 예를 들어 클라이언트가 매번 다시 다운로드할 필요가 없는 "요청 메시지를 제출해 주셔서 감사합니다"가 있습니다. RFC 7231은 여전히 섹션 4.2.2에서 POST가 멱등성이 아님을 유지하고 POST를 생성에 사용해야 한다고 계속 유지합니다.

이에 대한 자세한 내용은 이 문서를 참조하십시오 .

답변자 : metamatt

나는 RFC 2616의 PUT 정의 에서 이 조언을 좋아합니다.

POST 요청과 PUT 요청 간의 근본적인 차이점은 Request-URI의 다른 의미에 반영됩니다. POST 요청의 URI는 동봉된 엔터티를 처리할 리소스를 식별합니다. 해당 리소스는 데이터 수락 프로세스, 다른 프로토콜에 대한 게이트웨이 또는 주석을 수락하는 별도의 엔터티일 수 있습니다. 대조적으로, PUT 요청의 URI는 요청에 포함된 엔티티를 식별합니다. 사용자 에이전트는 URI가 무엇인지 알고 있으며 서버는 요청을 다른 리소스에 적용하려고 시도해서는 안 됩니다(MUST NOT).

PUT은 이미 이름이 있는 리소스에 가장 잘 적용되고 POST는 기존 리소스 아래에 새 개체를 만드는 데 적합합니다(그리고 서버에서 이름을 지정하도록 함).

나는 이것을 의미하고 PUT에 대한 멱등성 요구 사항을 다음과 같이 해석합니다.

• POST는 컬렉션 아래에 새 객체를 만드는 데 유용합니다(그리고 create는 멱등성이 필요하지 않습니다).
• PUT은 기존 객체를 업데이트하는 데 적합합니다(업데이트가 멱등적이어야 함).
• POST는 기존 개체에 대한 비멱등성 업데이트에도 사용할 수 있습니다(특히 전체를 지정하지 않고 개체의 일부를 변경하는 경우 -- 생각해 보면 컬렉션의 새 구성원을 만드는 것은 실제로 이러한 종류의 특별한 경우입니다. 컬렉션의 관점에서 업데이트)
• 클라이언트가 리소스의 이름을 지정할 수 있도록 허용한 경우에만 PUT을 생성에 사용할 수도 있습니다. 그러나 REST 클라이언트는 URL 구조에 대한 가정을 해서는 안 되므로 의도한 바가 적습니다.

답변자 : bharatj

간단히 말해서:

PUT 은 동일한 작업이 한 번 또는 여러 번 실행되는 경우 리소스 상태가 동일하게 되는 멱등성입니다.

POST 는 멱등성이 아니므로 작업이 한 번 실행하는 것과 비교하여 여러 번 실행되는 경우 리소스 상태가 다를 수 있습니다.

데이터베이스 쿼리와 유추

PUT "UPDATE STUDENT SET address = "abc" where id="123";

POST "INSERT INTO STUDENT(name, address) VALUES ("abc", "xyzzz");

학생 ID는 자동 생성됩니다.

PUT을 사용하면 동일한 쿼리가 여러 번 또는 한 번 실행되는 경우 STUDENT 테이블 상태가 동일하게 유지됩니다.

POST의 경우 동일한 쿼리가 여러 번 실행되면 데이터베이스에 여러 학생 레코드가 생성되고 "INSERT" 쿼리가 실행될 때마다 데이터베이스 상태가 변경됩니다.

참고: PUT에는 업데이트가 필요한 리소스 위치(이미 리소스)가 필요하지만 POST에는 필요하지 않습니다. 따라서 직관적으로 POST는 새 리소스 생성을 위한 반면 PUT은 이미 존재하는 리소스를 업데이트하는 데 필요합니다.

일부는 업데이트를 POST로 수행할 수 있다고 생각할 수 있습니다. 업데이트에 사용하거나 생성에 사용할 엄격한 규칙은 없습니다. 다시 이것들은 관례이며, 직관적으로 나는 위에서 언급한 추론에 관심이 있고 그것을 따릅니다.

답변자 : Homer6

POST는 편지를 사서함에 게시하거나 전자 메일 대기열에 전자 메일을 게시하는 것과 같습니다. PUT은 물건을 cubby hole이나 선반 위의 장소에 놓을 때와 같습니다(알려진 주소가 있음).

POST를 사용하면 QUEUE 또는 COLLECTION의 주소로 게시하게 됩니다. PUT을 사용하면 ITEM의 주소로 이동합니다.

PUT은 멱등원입니다. 요청을 100번 보낼 수 있으며 문제가 되지 않습니다. POST는 멱등성이 아닙니다. 요청을 100번 보내면 우편함에서 100개의 이메일 또는 100개의 편지를 받게 됩니다.

일반적인 규칙: 항목의 ID나 이름을 알고 있으면 PUT을 사용합니다. 받는 쪽에서 항목의 id 또는 이름을 지정 하려면 POST를 사용 합니다.

답변자 : ishandutta2007

짧은 답변:

간단한 경험 법칙: POST를 사용하여 생성하고 PUT을 사용하여 업데이트합니다.

긴 답변:

우편:

• POST는 서버에 데이터를 보내는 데 사용됩니다.
• 리소스의 URL을 알 수 없는 경우에 유용합니다.

놓다:

• PUT은 서버에 상태를 전송하는 데 사용됩니다.
• 리소스의 URL이 알려진 경우에 유용합니다.

더 긴 답변:

그것을 이해하려면 PUT이 필요한 이유, PUT이 해결하려고 하는 문제 중 POST가 할 수 없는 문제가 무엇인지 질문해야 합니다.

REST 아키텍처의 관점에서 볼 때 중요한 것은 없습니다. PUT 없이도 살 수 있었습니다. 그러나 클라이언트 개발자의 관점에서 볼 때 그것은 그들의 삶을 훨씬 더 단순하게 만들었습니다.

PUT 이전에는 클라이언트가 서버가 생성한 URL을 직접 알 수 없었고 모든 URL이 생성되었는지 또는 서버로 보낼 데이터가 이미 업데이트되었는지 여부를 알 수 없었습니다. PUT은 이러한 모든 골칫거리의 개발자를 덜어줍니다. PUT은 멱등성이고 PUT은 경쟁 조건을 처리하며 PUT은 클라이언트가 URL을 선택할 수 있도록 합니다.

답변자 : Jordan

새로운 답변(이제 REST를 더 잘 이해하게 되었습니다):

PUT은 이제부터 클라이언트가 식별한 리소스의 표현을 렌더링하기 위해 서비스가 사용해야 하는 콘텐츠에 대한 설명일 뿐입니다. POST는 이제부터 서비스에 포함되어야 하는 콘텐츠(복제될 수 있음)에 대한 설명이지만 해당 콘텐츠를 식별하는 방법은 서버에 달려 있습니다.

PUT x (만약 x 식별하는 자원 ) "로 식별되는 자원의 내용 교체 x . 내 컨텐츠를"

PUT x ( x 가 리소스를 식별하지 않는 경우): "내 콘텐츠가 포함된 새 리소스를 만들고 x 를 사용하여 식별합니다."

POST x : "내 콘텐츠를 저장하고 해당 콘텐츠(다른 콘텐츠와 혼합될 수 있음)를 포함하는 리소스(이전 또는 신규)를 식별하는 데 사용할 수 있는 식별자를 제공합니다. 해당 리소스는 x 식별하는 것과 동일하거나 종속되어야 합니다." " y 의 리소스는 x 의 리소스에 종속됩니다 "는 일반적으로 y 를 x 의 하위 경로(예: x = /foo 및 y = /foo/bar )로 만들고 x '의 표현을 수정하여 구현되지만 반드시 필요한 것은 아닙니다. 예를 들어 y 의 리소스 및 일부 메타데이터에 대한 하이퍼링크와 함께 새 리소스의 존재를 반영하는 s 리소스. REST에서는 URL이 불투명하므로 후자만 좋은 디자인에 정말 중요합니다. 어쨌든 서비스를 트래버스하려면 클라이언트 측 URL 구성 대신 하이퍼미디어를 사용해야 합니다.

REST에는 "콘텐츠"를 포함하는 리소스와 같은 것이 없습니다. 서비스가 표현을 일관되게 렌더링하는 데 사용하는 데이터를 "컨텐츠"라고 합니다. 일반적으로 데이터베이스 또는 파일(예: 이미지 파일)의 일부 관련 행으로 구성됩니다. 사용자의 콘텐츠를 서비스에서 사용할 수 있는 것으로 변환하는 것은 서비스에 달려 있습니다(예: JSON 페이로드를 SQL 문으로 변환).

원래 답변(더 읽기 쉬울 수 있음) :

PUT /something ( /something 이미 존재하는 경우): " /something 있는 모든 것을 가져 와서 내가 주는 것으로 대체하십시오."

PUT /something ( /something 이 이미 존재하지 않는 경우 ): "내가 주는 것을 받아 /something 넣으십시오 ."

POST /something : "내가 당신에게 주는 것을 가지고 당신이 끝냈을 때 URL을 알려주기만 하면 /something 아래에 원하는 아무 곳에나 두십시오."

답변자 : germanlinux

Ruby on Rails 4.0은 PUT 대신 'PATCH' 메서드를 사용하여 부분 업데이트를 수행합니다.

RFC 5789는 PATCH(1995년 이후)에 대해 다음과 같이 말합니다.

상호 운용성을 높이고 오류를 방지하려면 새로운 방법이 필요합니다. PUT 메서드는 리소스를 완전히 새 본문으로 덮어쓰도록 이미 정의되어 있으며 부분 변경을 수행하는 데 재사용할 수 없습니다. 그렇지 않으면 프록시와 캐시, 심지어 클라이언트와 서버도 작업 결과에 대해 혼동을 일으킬 수 있습니다. POST는 이미 사용되지만 광범위한 상호 운용성은 없습니다(하나는 패치 형식 지원을 검색하는 표준 방법이 없음). PATCH는 이전 HTTP 사양에서 언급되었지만 완전히 정의되지는 않았습니다.

" Edge Rails: PATCH는 업데이트를 위한 새로운 기본 HTTP 방법입니다 "라고 설명합니다.

답변자 : skillet-thief

이미 말한 것을 다시 말할 위험이 있지만 PUT 은 리소스를 생성할 때 클라이언트가 URL 이 무엇인지 제어한다는 것을 의미한다는 것을 기억하는 것이 중요합니다. 따라서 PUT 과 POST 중에서 선택하는 부분은 URL 체계가 무엇이든 간에 일관성 있는 정확하고 정규화된 URL 을 제공하기 위해 클라이언트를 얼마나 신뢰할 수 있는지에 관한 것입니다.

클라이언트가 올바른 작업을 수행하도록 완전히 신뢰할 수 없는 경우 POST 를 사용하여 새 항목을 만든 다음 응답에서 URL을 클라이언트에 다시 보내는 것이 더 적절할 것입니다.

답변자 : UniCoder

아주 간단한 방법으로 저는 Facebook 타임라인의 예를 들고 있습니다.

사례 1: 타임라인에 무언가를 게시하면 새로운 항목이 됩니다. 따라서 이 경우 POST 메서드가 멱등성이 아니기 때문에 POST 메서드를 사용합니다.

사례 2: 친구가 처음으로 게시물에 댓글을 달면 데이터베이스에 새 항목이 생성되어 POST 메서드가 사용됩니다.

사례 3: 친구가 댓글을 편집하는 경우 이 경우 댓글 ID가 있으므로 데이터베이스에 새 항목을 만드는 대신 기존 댓글을 업데이트합니다. 따라서 이러한 유형의 작업에는 멱등성이므로 PUT 메서드를 사용합니다.*

한 줄에서 POST 를 사용하여 데이터베이스에 새 항목 을 추가 하고 PUT 을 사용 하여 데이터베이스에서 항목을 업데이트합니다.

답변자 : Hans Malherbe

가장 중요한 고려 사항은 신뢰성 입니다. POST 메시지가 손실되면 시스템 상태가 정의되지 않습니다. 자동 복구가 불가능합니다. PUT 메시지의 경우 상태는 첫 번째 성공적인 재시도까지만 정의되지 않습니다.

예를 들어 POST로 신용 카드 거래를 생성하는 것은 좋은 생각이 아닐 수 있습니다.

리소스에 자동 생성된 URI가 있는 경우 생성된 URI(빈 리소스를 가리킴)를 클라이언트에 전달하여 PUT을 계속 사용할 수 있습니다.

기타 고려 사항:

• POST는 포함된 전체 리소스의 캐시된 복사본을 무효화합니다(더 나은 일관성).
• PUT 응답은 캐시할 수 없는 반면 POST 응답은 캐시할 수 없습니다(Content-Location 및 만료 필요).
• PUT은 예를 들어 Java ME, 이전 브라우저, 방화벽에서 덜 지원됩니다.

답변자 : Rohit Dhiman

다른 사람들이 제안한 차이점 외에도 하나 더 추가하고 싶습니다.

POST 방법에서는 form-data 에서 본문 매개변수를 보낼 수 있습니다.

PUT 방법에서는 x-www-form-urlencoded 로 본문 매개변수를 보내야 합니다.

헤더 Content-Type:application/x-www-form-urlencoded

이에 따르면 PUT 방식으로 파일이나 멀티파트 데이터를 보낼 수 없습니다.

편집하다

"application/x-www-form-urlencoded" 콘텐츠 유형은 ASCII가 아닌 문자가 포함된 대량의 이진 데이터 또는 텍스트를 보내는 데 비효율적입니다. "multipart/form-data" 콘텐츠 유형은 파일, 비ASCII 데이터 및 이진 데이터가 포함된 양식을 제출하는 데 사용해야 합니다.

제출해야 하는 경우

파일, 비 ASCII 데이터 및 바이너리 데이터

당신은 POST 방법을 사용해야합니다

답변자 : bbsimonbb

이 주제를 처음 접하는 독자는 무엇을 해야 하는지에 대한 끝없는 토론과 경험에서 얻을 수 있는 교훈의 상대적 부재에 충격을 받을 것입니다. REST가 SOAP보다 "선호"된다는 사실은 경험을 통한 높은 수준의 학습이지만 거기에서 발전했음에 틀림없다고 생각합니다. 2016년입니다. Roy의 논문은 2000년이었습니다. 우리는 무엇을 개발했습니까? 재밌었 어? 통합하기 쉬웠나요? 지원하려면? 스마트폰의 증가와 불안정한 모바일 연결을 처리할 수 있습니까?

ME에 따르면 실제 네트워크는 신뢰할 수 없습니다. 시간 초과를 요청합니다. 연결이 재설정됩니다. 네트워크는 한 번에 몇 시간 또는 며칠 동안 다운됩니다. 기차는 모바일 사용자와 함께 터널로 들어갑니다. 모든 주어진 요청(이 모든 논의에서 때때로 인정됨)에 대해 요청은 도중에 물에 빠지거나 응답은 돌아오는 도중 물에 빠질 수 있습니다. 이러한 조건에서 실질적인 리소스에 대해 직접 PUT, POST 및 DELETE 요청을 실행하는 것은 항상 저에게 약간 잔인하고 순진한 것처럼 느껴졌습니다.

HTTP는 요청-응답의 안정적인 완료를 보장하기 위해 아무 것도 하지 않으며 이것이 네트워크 인식 응용 프로그램의 적절한 작업이기 때문에 괜찮습니다. 이러한 애플리케이션을 개발하면 POST 대신 PUT을 사용하기 위해 후프를 건너뛸 수 있으며 중복 요청을 감지하면 서버에서 특정 종류의 오류를 제공하기 위해 더 많은 후프를 사용할 수 있습니다. 클라이언트로 돌아가서 이러한 오류를 해석하고, 다시 가져오고, 재검증하고, 다시 게시하려면 여러 단계를 거쳐야 합니다.

또는 다음과 같이 할 수 있습니다 . 안전하지 않은 요청을 임시 단일 사용자 리소스로 간주합니다(이를 작업이라고 합시다). 클라이언트는 리소스에 대한 빈 POST를 사용하여 실질적인 리소스에 대한 새로운 "작업"을 요청합니다. 이 경우에만 POST가 사용됩니다. 새로 생성된 작업의 URI를 안전하게 소유하면 클라이언트는 안전하지 않은 요청을 대상 리소스가 아닌 작업 URI에 PUT합니다. 작업을 해결하고 "실제" 리소스를 업데이트하는 것은 API의 적절한 작업이며 여기서 신뢰할 수 없는 네트워크와 분리됩니다.

서버는 비즈니스를 수행하고 응답을 반환 하고 합의된 작업 URI에 대해 저장합니다 . 문제가 발생하면 클라이언트는 요청을 반복하고(자연스러운 동작!) 서버가 이미 이를 확인한 경우 저장된 응답을 반복하고 다른 작업은 수행하지 않습니다 .

프라미스의 유사성을 빠르게 발견할 수 있습니다. 작업을 수행하기 전에 결과에 대한 자리 표시자를 만들고 반환합니다. 또한 프라미스처럼 액션은 한 번 성공하거나 실패할 수 있지만 그 결과는 반복적으로 가져올 수 있습니다.

무엇보다도 우리는 송신 및 수신 애플리케이션에 고유하게 식별된 작업을 해당 환경의 고유성과 연결할 수 있는 기회를 제공합니다. 그리고 우리는 클라이언트로부터 책임 있는 행동을 요구하고 시행할 수 있습니다. 원하는 만큼 요청을 반복하되 기존 작업에서 결정적인 결과를 얻을 때까지 새로운 작업을 생성하지 마십시오.

따라서 수많은 까다로운 문제가 사라집니다. 반복된 삽입 요청은 중복을 생성하지 않으며 데이터를 소유할 때까지 실제 리소스를 생성하지 않습니다. (데이터베이스 열은 nullable이 아닌 상태로 유지될 수 있습니다.) 반복된 업데이트 요청은 호환되지 않는 상태에 도달하지 않으며 후속 변경 사항을 덮어쓰지 않습니다. 클라이언트는 어떤 이유로든(클라이언트 충돌, 응답 누락 등) 원래 확인을 (재)패치하고 원활하게 처리할 수 있습니다.

연속 삭제 요청은 404 오류가 발생하지 않고 원래 확인을 보고 처리할 수 있습니다. 예상보다 시간이 오래 걸리는 경우 잠정적으로 대응할 수 있으며, 고객이 최종 결과를 확인할 수 있는 곳이 있습니다. 이 패턴의 가장 좋은 부분은 쿵푸(판다) 속성입니다. 우리는 클라이언트가 응답을 이해하지 못할 때마다 요청을 반복하는 경향, 약점을 취하고 그것을 강점으로 만듭니다 :-)

이것이 RESTful이 아니라고 말하기 전에 REST 원칙이 존중되는 다양한 방법을 고려하십시오. 클라이언트는 URL을 구성하지 않습니다. API는 의미 체계가 약간 변경되기는 하지만 검색 가능한 상태를 유지합니다. HTTP 동사가 적절하게 사용됩니다. 이것이 구현해야 할 큰 변화라고 생각하신다면 경험상 그렇지 않다고 말씀드릴 수 있습니다.

저장해야 할 데이터가 엄청나다고 생각한다면 볼륨에 대해 이야기해 보겠습니다. 일반적인 업데이트 확인은 킬로바이트의 일부에 불과합니다. HTTP는 현재 확실하게 응답하는 데 1~2분의 시간을 제공합니다. 일주일 동안만 작업을 저장하더라도 클라이언트가 따라잡을 수 있는 충분한 기회가 있습니다. 볼륨이 매우 큰 경우 전용 산 호환 키 값 저장소 또는 인메모리 솔루션이 필요할 수 있습니다.

답변자 : Burhan

REST 서비스에 대해 HTTP POST와 HTTP PUT 방법을 언제 사용해야 하는지에 대해 항상 약간의 혼란이 있는 것 같습니다. 대부분의 개발자는 CRUD 작업을 HTTP 메서드에 직접 연결하려고 합니다. 나는 이것이 옳지 않으며 CRUD 개념을 HTTP 메소드에 단순히 연관시킬 수 없다고 주장할 것입니다. 그건:

 Create => HTTP PUT Retrieve => HTTP GET Update => HTTP POST Delete => HTTP DELETE

CRUD 작업의 R(etrieve) 및 D(elete)를 각각 HTTP 메서드 GET 및 DELETE에 직접 매핑할 수 있는 것은 사실입니다. 그러나 혼란은 C(reate) 및 U(update) 작업에 있습니다. 어떤 경우에는 생성을 위해 PUT을 사용할 수 있고 다른 경우에는 POST가 필요할 것입니다. 모호성은 HTTP PUT 메서드와 HTTP POST 메서드의 정의에 있습니다.

HTTP 1.1 사양에 따르면 GET, HEAD, DELETE 및 PUT 메서드는 멱등해야 하고 POST 메서드는 멱등하지 않아야 합니다. 즉, 작업이 리소스에 대해 한 번 또는 여러 번 수행될 수 있고 항상 해당 리소스의 동일한 상태를 반환할 수 있는 경우 작업은 멱등적입니다. 반면 비멱등 작업은 한 요청에서 다른 요청으로 리소스의 수정된 상태를 반환할 수 있습니다. 따라서 멱등성이 없는 작업에서는 리소스의 동일한 상태를 받을 것이라는 보장이 없습니다.

위의 멱등원 정의에 따라 REST 서비스에 대해 HTTP PUT 메서드를 사용하는 것과 HTTP PUT 메서드를 사용하는 것에 대한 제 생각은 다음과 같습니다.

 The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee. The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

두 경우 모두 동일한 결과로 이러한 작업을 여러 번 수행할 수 있습니다. 즉, 작업을 두 번 이상 요청하여 리소스가 변경되지 않습니다. 따라서 진정한 멱등 연산입니다. 다음과 같은 경우 HTTP POST 메서드를 사용합니다.

 The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client. On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

결론

CRUD 작업을 REST 서비스에 대한 HTTP 메서드에 직접 연관시키고 매핑하지 마십시오. HTTP PUT 방법과 HTTP POST 방법의 사용은 해당 작업의 멱등적 측면을 기반으로 해야 합니다. 즉, 작업이 멱등성인 경우 HTTP PUT 메서드를 사용합니다. 작업이 멱등성이 아닌 경우 HTTP POST 메서드를 사용합니다.

답변자 : inf3rno

원본 서버는 해당 URI로 리소스를 생성할 수 있습니다.

따라서 POST를 사용하고 아마도 리소스 생성에 필요한 PUT은 아닙니다. 둘 다 지원할 필요는 없습니다. 나를 위해 POST는 완벽하게 충분합니다. 따라서 디자인 결정입니다.

인용문에서 언급했듯이 IRI에 할당된 리소스가 없고 어쨌든 리소스를 생성하기 위해 PUT을 사용합니다. 예를 들어, PUT /users/123/password 일반적으로 이전 비밀번호를 새 비밀번호로 대체하지만, 비밀번호가 아직 없는 경우(예: 새로 등록한 사용자 또는 차단된 사용자를 복원하여) 비밀번호를 생성하는 데 사용할 수 있습니다.

답변자 : Gerard ONeill

다음과 같이 착륙하겠습니다.

PUT은 URI로 식별되는 리소스를 나타냅니다. 이 경우 업데이트하고 있습니다. 리소스를 나타내는 세 동사의 일부입니다. 삭제 및 다른 두 가지가 됩니다.

POST는 기본적으로 '대역 외'로 정의되는 자유 형식 메시지입니다. 메시지가 디렉토리에 리소스를 추가하는 것으로 해석될 수 있다면 괜찮을 것입니다. 그러나 기본적으로 리소스에 어떤 일이 일어날지 알기 위해 보내는(게시) 메시지를 이해해야 합니다.

---

PUT 및 GET 및 DELETE는 리소스를 참조하므로 정의상 멱등원이기도 합니다.

POST는 다른 세 가지 기능을 수행할 수 있지만 요청의 의미는 캐시 및 프록시와 같은 중개자에서 손실됩니다. 이는 게시물의 URI가 해당 게시물이 적용되는 리소스를 반드시 나타내지는 않기 때문에 리소스에 대한 보안을 제공하는 데에도 적용됩니다(그래도 가능).

PUT은 생성일 필요가 없습니다. 리소스가 아직 생성되지 않은 경우 서비스에 오류가 발생할 수 있지만 그렇지 않으면 업데이트합니다. 또는 그 반대의 경우도 마찬가지입니다. 리소스를 생성할 수 있지만 업데이트는 허용하지 않습니다. PUT에 대해 필요한 유일한 것은 특정 리소스를 가리키고 해당 페이로드는 해당 리소스의 표현이라는 것입니다. 성공적인 PUT은 GET가 동일한 리소스를 검색할 것임을 의미합니다(간섭 제외).

---

편집: 한 가지 더 -- PUT이 생성할 수 있지만 그렇게 하는 경우 ID는 이메일 주소라고도 하는 자연 ID여야 합니다. 그렇게 하면 두 번 PUT할 때 두 번째 put은 첫 번째 put의 업데이트입니다. 이렇게 하면 멱등성이 됩니다.

ID가 생성된 경우(예: 새 직원 ID) 동일한 URL을 가진 두 번째 PUT은 멱등원 규칙을 위반하는 새 레코드를 생성합니다. 이 경우 동사는 POST이고 메시지(리소스 아님)는 이 메시지에 정의된 값을 사용하여 리소스를 생성하는 것입니다.

답변자 : Gregory Magarshak

의미론은 "GET"과 같은 "PUT"이 멱등적이어야 한다는 점에서 다릅니다. 즉, 동일한 정확한 PUT 요청을 여러 번 수행할 수 있으며 결과는 한 번만 실행한 것과 같습니다.

가장 널리 사용되고 가장 유용하다고 생각되는 규칙에 대해 설명하겠습니다.

특정 URL에 리소스를 PUT하면 해당 URL 또는 해당 행을 따라 저장되어야 합니다.

특정 URL의 리소스에 POST를 수행하면 해당 URL에 관련 정보를 게시하는 경우가 많습니다. 이는 URL의 리소스가 이미 존재함을 의미합니다.

예를 들어, 새 스트림을 만들고 싶을 때 어떤 URL에 PUT할 수 있습니다. 그러나 기존 스트림에 메시지를 POST하려는 경우 해당 URL에 POST합니다.

스트림의 속성을 수정하는 경우 PUT 또는 POST를 사용하여 수정할 수 있습니다. 기본적으로 작업이 멱등원일 때만 "PUT"을 사용하고 그렇지 않으면 POST를 사용합니다.

그러나 모든 최신 브라우저가 GET 또는 POST 이외의 HTTP 동사를 지원하는 것은 아닙니다.

답변자 : tothemario

대부분의 경우 다음과 같이 사용합니다.

• 리소스를 컬렉션에 게시
• collection/:id로 식별되는 리소스를 PUT

예를 들어:

• POST /항목
• PUT /items/1234

두 경우 모두 요청 본문에는 생성하거나 업데이트할 리소스에 대한 데이터가 포함됩니다. 경로 이름에서 POST가 멱등적이지 않다는 것이 분명해야 합니다(세 번 호출하면 3개의 개체가 생성됨). 그러나 PUT은 멱등성이 있습니다(3번 호출하면 결과가 동일함). PUT은 종종 "upsert" 작업(생성 또는 업데이트)에 사용되지만 수정하는 데만 사용하려는 경우 항상 404 오류를 반환할 수 있습니다.

POST는 컬렉션의 새 요소를 "생성"하고 PUT은 주어진 URL에서 요소를 "대체"하지만 부분 수정을 위해 PUT을 사용하는 것이 매우 일반적인 관행입니다. 즉, 기존 리소스를 업데이트하고 본문에 포함된 필드만 수정합니다(다른 필드는 무시). 이것은 기술적으로 올바르지 않습니다. REST-purist가 되려면 PUT이 전체 리소스를 대체해야 하고 부분 업데이트에 PATCH를 사용해야 합니다. 저는 개인적으로 모든 API 엔드포인트에서 동작이 명확하고 일관성이 있는 한 크게 신경 쓰지 않습니다.

REST는 API를 단순하게 유지하기 위한 일련의 규칙 및 지침임을 기억하십시오. "RESTfull" 상자를 선택하기 위해 복잡한 해결 방법으로 끝나면 목적을 달성하지 못하는 것입니다 ;)

답변자 : Adam Griffiths

다음은 간단한 규칙입니다.

URL에 대한 PUT 은 해당 URL에 있을 수 있는 리소스를 업데이트하거나 생성하는 데 사용해야 합니다.

URL에 대한 POST 는 다른("하위") URL에 있거나 HTTP를 통해 찾을 수 없는 리소스를 업데이트하거나 생성하는 데 사용해야 합니다.

답변자 : Rajan

데이터베이스 작업에 익숙하다면 다음이 있습니다.

1. 선택하다
2. 끼워 넣다
3. 업데이트
4. 삭제
5. 병합(이미 존재하는 경우 업데이트, 그렇지 않으면 삽입)

병합 및 업데이트에는 PUT 을 사용하고 삽입 POST

답변자 : Tom Stickel

이것을 설명하는 불가지론적 방법이 있을 수 있지만 웹사이트에 대한 답변의 다양한 진술과 충돌하는 것 같습니다.

여기에서 매우 명확하고 직접적으로 설명하겠습니다. Web API로 작업하는 .NET 개발자인 경우 사실(Microsoft API 설명서에서), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web -api-that-supports-crud-operations :

 1. PUT = UPDATE (/api/products/id) 2. MCSD Exams 2014 - UPDATE = PUT, there are **NO** multiple answers for that question period.

물론 "POST"를 사용하여 업데이트할 수 있지만 주어진 프레임워크에 대해 제시된 규칙을 따르십시오. 제 경우에는 .NET / Web API이므로 PUT은 UPDATE용 이므로 논쟁의 여지가 없습니다.

Amazon 및 Sun/Java 웹 사이트 링크가 포함된 모든 댓글을 읽는 모든 Microsoft 개발자에게 이것이 도움이 되길 바랍니다.

답변자 : java_geek

실제로 POST는 리소스 생성에 적합합니다. 새로 생성된 리소스의 URL은 Location 응답 헤더에 반환되어야 합니다. 리소스를 완전히 업데이트하려면 PUT을 사용해야 합니다. RESTful API를 설계할 때의 모범 사례임을 이해하십시오. HTTP 사양은 리소스 생성/업데이트에 대한 몇 가지 제한 사항이 있는 PUT/POST 사용을 제한하지 않습니다. 모범 사례를 요약한 http://techoctave.com/c7/posts/71-twitter-rest-api-dissected 를 살펴보십시오.

출처 : Here

출처 : http:www.stackoverflow.com/questions/630453/what-is-the-difference-between-post-and-put-in-http">