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

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

배경 정보 분석:

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

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

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

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

내 질문:

그렇다면, 자원을 만들기 위해 어떤 HTTP 방법을 사용해야 할까요?아니면 둘 다 지원되어야 합니까?

전체:

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

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

좋습니다. 둘 다 사용할 수 있으니 RESTful 디자인에서 다음 중 어떤 것을 사용해야 합니까?

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

어느 것을 사용할지는 당신에게 달려 있습니다.그러나 요청에서 어떤 개체를 참조하는지에 따라 올바른 개체를 사용해야 합니다.

몇 가지 고려 사항:

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

예:

저는 이와 관련하여 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를 사용하여 URL을 생성하면 안 됩니다. 'found(리소스를 찾을 수 없음)'라는합니다.<new_question>존재하지 않습니다.당신은 그것을 넣어야 합니다.<new_question>먼저 서버의 리소스를 검색합니다.

POST를 사용하여 리소스를 생성하려면 다음과 같은 작업을 수행할 수 있습니다.

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

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

PUT:

리소스를 만들거나 덮어쓰는 데 사용됩니다.리소스를 지정하는 동안 새 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

를 PUT로 합니다.created또는replaced요청 메시지 페이로드에 포함된 표현으로 정의된 상태를 사용합니다.

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

• POST를 사용하여 리소스를 생성하고 PUT를 사용하여 리소스를 수정해야 합니다.
• PUT를 사용하여 리소스를 생성하고 POST를 사용하여 리소스를 수정해야 합니다.

둘 다 옳지 않습니다.

---

동작의 동일성에 따라 PUT과 POST 중 하나를 선택하는 것이 좋습니다.

PUT는 주어진 URL에서 사용 가능한 모든 것을 다른 것으로 완전히 대체하는 리소스를 의미합니다.정의에 따라 PUT는 동일합니다.원하는 만큼 하면 결과는 같습니다. x=5실력이 충분하지 않습니다.리소스가 이전에 존재하는지 여부에 관계없이 리소스를 배치할 수 있습니다(예: 만들기 또는 업데이트)!

POST는 리소스를 업데이트하거나 보조 리소스를 추가하거나 변경을 발생시킵니다.POST는 다음과 같은 점에서 동일하지 않습니다.x++동일한 능력이 없습니다.

---

이 주장에 따르면 PUT는 생성할 대상의 URL을 알고 있을 때 생성하기 위한 것입니다.POST는 생성하려는 항목 범주에 대한 "공장" 또는 관리자의 URL을 알고 있을 때 생성하는 데 사용할 수 있습니다.

그래서:

POST /expense-report

또는:

PUT  /expense-report/10929

• URL에 POST하면 서버 정의 URL에 하위 리소스가 생성됩니다.
• PUT to URL은 클라이언트 정의 URL에서 리소스 전체를 생성/교체합니다.
• URL에 패치를 적용하면 해당 클라이언트 정의 URL에 있는 리소스의 일부가 업데이트됩니다.

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

POST는 하위 리소스를 생성하므로 다음에 게시합니다./items▁under에 있는 합니다./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가 무엇을 의도하는지 알고 있으며 서버는 요청을 다른 리소스에 적용하려고 해서는 안 됩니다.서버가 요청을 다른 URI에 적용하기를 원하는 경우,

참고: PUT는 대부분 리소스를 업데이트하는 데 사용되었지만, PUT가 전체 리소스를 대체하도록 지정함에 따라 최근에는 기존 리소스를 업데이트하는 데 PATCH를 사용하는 추세입니다.RFC 5789.

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

"REST without PUT" 기술을 사용하면 소비자는 새로운 '통합되지 않은' 요청 리소스를 게시해야 합니다.앞에서 설명한 바와 같이, 고객의 메일 주소를 변경하는 것은 새로운 "ChangeOfAddress" 리소스에 대한 POST이지, 메일 주소 필드 값이 다른 "Customer" 리소스에 대한 PUT가 아닙니다.

REST API Design에서 가져온 - Thinkworks의 Prakash Subramaniam에 의한 자원 모델링

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

POST는 "사용자를 생성하기 위한 입력입니다, 생성해 주세요"와 같이 "새로 생성"을 의미합니다.

PUT는 " the 5와 "의미합니다. "Here is the data for user 5"는 "Insert, replace if existed"입니다.

은 너POSTexample.com/users 을 example.com/users 으로 이동하십시오.URL아직 사용자의 서버에서 작성하기를 원합니다.

은 너PUT특정 사용자를 교체/생성하려는 경우 example.com/users/id 으로 이동합니다.

두번 두 ).동일한 데이터를 두 번 입력하면 첫 번째 사용자가 생성되고 두 번째에는 동일한 상태로 업데이트됩니다(변경 사항 없음).나중에 같은 상태가 되기 때문에.PUT당신이 그것을 몇 번이나 수행하든, 그것은 매번 "매우 강력하다"고 합니다 - 동일한 능력입니다.이 기능은 자동으로 요청을 재시도하는 데 유용합니다.브라우저의 뒤로 단추를 누르면 '재전송하시겠습니까?'가 더 이상 표시되지 않습니다.

은 일적인조다같다습니과음은을 사용하는 것입니다.POST가 서를제하경는우야해를 해야 할 때.URL리소스 생성.사용하다PUT그렇지않으면.선호하다PUT1파운드가 POST.

요약:.

작성:

다음과 같은 방법으로 PUT 또는 POST를 모두 수행할 수 있습니다.

놓다

newResourceId를 식별자로 사용하여 /resourcesURI 또는 컬렉션 아래에 새 리소스를 생성합니다.

PUT /resources/<newResourceId> HTTP/1.1

포스트.

/resources URI 또는 컬렉션 아래에 새 리소스를 생성합니다.일반적으로 식별자는 서버에서 반환됩니다.

POST /resources HTTP/1.1

업데이트:

다음과 같은 방법으로만 PUT를 사용하여 수행할 수 있습니다.

놓다

기존 ResourceId를 식별자로 사용하거나 /resourcesURI 또는 컬렉션 아래에 있는 리소스를 업데이트합니다.

PUT /resources/<existingResourceId> HTTP/1.1

설명:

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

예:

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

URI: website.example/users/john
website.example  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.example/users/john/posts/23
website.example  - 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

서버 업데이트를 알려주거나, 업데이트가 없는 경우 사용자 모음 아래에 존 리소스를 작성합니다.

사양:

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

포스트.

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

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

놓다

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

따라서 리소스의 존재에 따라 생성하거나 업데이트합니다.

참조:

• HTTP/1.1 사양
• 위키백과 - REST
• IMT2000 3GPP - URI : 일반 구문과 의미론

저는 제 "실용적인" 조언을 덧붙이고 싶습니다.저장 중인 개체를 검색할 수 있는 "ID"를 알고 있으면 PUT를 사용합니다.예를 들어, 데이터베이스 생성 ID를 반환하여 이후 검색 또는 업데이트를 수행해야 하는 경우 PUT를 사용하면 잘 작동하지 않습니다.

So: 기존 사용자를 저장하거나 클라이언트가 ID를 생성하고 ID가 고유한지 확인하는 사용자를 저장하려면:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.example

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.example

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

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

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.example

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

놓다	포스트.
기존 리소스를 바꾸거나 리소스가 없는 경우 생성합니다. 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를 사용하여 만들고 PUT을 사용하여 업데이트합니다.어쨌든 루비 온 레일즈가 그렇게 하고 있어요.

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

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

HTTP에서 REST를 구현하는 방법에 대해 의문이 있는 경우 언제든지 AtomPub(AtomPub) 사양을 확인할 수 있습니다.AtomPub은 HTTP로 RESTful 웹 서비스를 작성하기 위한 표준으로, 많은 HTTP 및 REST 조명자들에 의해 개발되었으며, REST의 발명자이자 HTTP의 공동 발명자인 Roy Fielding이 일부 입력했습니다.

사실, 당신은 심지어 AtomPub을 직접 사용할 수도 있습니다.블로그 커뮤니티에서 나온 것이지만, 그것은 결코 블로그에 국한되지 않습니다: 그것은 HTTP를 통해 임의의 (내포된) 임의의 자원 컬렉션과 완전히 상호 작용하기 위한 일반 프로토콜입니다.응용프로그램을 중첩된 리소스 모음으로 나타낼 수 있는 경우, PUT 또는 POST를 사용할지, 반환할 HTTP 상태 코드 및 이러한 모든 세부 정보에 대해 걱정하지 않고 AtomPub을 사용할 수 있습니다.

AtomPub은 리소스 생성에 대해 다음과 같이 말합니다(섹션 9.2).

컬렉션에 멤버를 추가하기 위해 클라이언트는 컬렉션의 URI로 POST 요청을 보냅니다.

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

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

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

http://roy.gbiv.com/untangled/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단계는 사람들이 흔히 무엇을 해야 할지 혼란스러워하는 단계입니다.하지만, 이 문제를 해결하기 위해 슬럼프를 만들 이유가 없습니다.대신 RFC 2616에 지정된 대로 HTTP를 사용할 수 있으며 서버는 다음과 같이 응답합니다.

10.4.10 409 충돌

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

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

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

상태 코드 409 충돌로 회신하는 것이 올바른 방법입니다. 이유는 다음과 같습니다.

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

RFC 7231 릴리스를 기반으로 2616을 교체하는 업데이트

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

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

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

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

저는 RFC 2616의 PUT에 대한 정의에서 나온 다음과 같은 조언을 좋아합니다.

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

PUT는 이미 이름이 있는 리소스에 가장 잘 적용되며 POST는 기존 리소스 아래에 새 개체를 생성하고 서버에 이름을 지정하는 데 유용합니다.

저는 이것과 PUT에 대한 동일성 요구사항을 다음과 같은 의미로 해석합니다.

• POST는 컬렉션 아래에 새 개체를 생성하는 데 유용합니다(생성이 동일할 필요는 없음).
• PUT는 기존 개체를 업데이트하는 데 유용합니다(업데이트는 동일해야 함).
• POST는 기존 개체에 대한 비동일한 업데이트에도 사용될 수 있습니다(특히 전체를 지정하지 않고 개체의 일부를 변경하는 경우). 생각해보면 컬렉션의 관점에서 컬렉션의 새 멤버를 만드는 것은 실제로 이러한 업데이트의 특별한 경우입니다.
• PUT는 클라이언트가 리소스의 이름을 지정하도록 허용하는 경우에만 생성에 사용할 수 있습니다.그러나 REST 클라이언트는 URL 구조에 대해 가정을 하지 않아야 하기 때문에, 의도된 정신으로는 이것이 덜합니다.

간단히 말해서:

PUT는 동일하며, 동일한 작업이 한 번 또는 여러 번 실행되는 경우 리소스 상태가 동일합니다.

POST는 비등장성으로, 한 번 실행하는 것과 비교하여 작업을 여러 번 실행하는 경우 리소스 상태가 달라질 수 있습니다.

데이터베이스 쿼리와의 유사성

PUT "UPDATE STUDEN SET address = "debug"와 유사한 id="123";

게시물 "학생(이름, 주소) 값에 삽입"("abc", "xyzz")과 같은 것을 생각할 수 있습니다.

학생 ID가 자동으로 생성됩니다.

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

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

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

일부에서는 POST를 사용하여 업데이트를 수행할 수 있다고 생각할 수 있습니다.업데이트에 사용할 규칙이나 생성에 사용할 규칙은 없습니다.다시 말하지만 이것들은 관습이고, 직관적으로 저는 위에서 언급한 추론에 기울고 그것을 따릅니다.

POST는 편지함에 편지를 게시하거나 전자 메일 대기열에 전자 메일을 게시하는 것과 같습니다.PUT는 물체를 작은 구멍에 넣거나 선반에 있는 장소(알려진 주소를 가지고 있음)에 넣는 것과 같습니다.

POST를 사용하면 QUEST 또는 COLLECTION의 주소로 게시하고 PUT을 사용하면 항목의 주소로 게시합니다.

PUT는 동일합니다.당신은 요청을 100번 보낼 수 있고 그것은 문제가 되지 않을 것입니다.POST가 동일하지 않습니다.만약 당신이 100번의 요청을 보낸다면, 당신의 우편함에 100개의 이메일이나 100개의 편지를 받게 될 것입니다.

일반적인 규칙: 항목의 ID 또는 이름을 알고 있는 경우 PUT를 사용합니다.수신자가 항목의 ID 또는 이름을 할당하려면 POST를 사용합니다.

단답:

간단한 경험칙:POST를 사용하여 만들고 PUT를 사용하여 업데이트합니다.

긴 답변:

게시물:

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

PUT:

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

긴 답변:

이를 이해하기 위해서는 PUT이 왜 필요했는지, POST가 해결하지 못한 문제는 무엇인지 질문해야 합니다.

REST 아키텍처의 관점에서 볼 때 중요한 것은 없습니다.우리도 PUT 없이 살 수 있었습니다.그러나 고객 개발자의 관점에서 보면 이는 그/그녀의 삶을 훨씬 단순하게 만들었습니다.

PUT 이전에는 클라이언트가 서버가 생성한 URL을 직접 알 수 없었거나 서버에 전송할 데이터가 이미 업데이트되었는지 여부를 알 수 없었습니다.PUT는 개발자에게 이러한 모든 골칫거리를 덜어주었습니다.PUT는 동일하고, PUT는 레이스 조건을 처리하며, PUT는 클라이언트가 URL을 선택할 수 있도록 합니다.

새로운 답변(REST를 더 잘 이해하게 됨):

PUT는 이제부터 서비스가 클라이언트가 식별한 리소스의 표현을 렌더링하는 데 사용해야 하는 컨텐츠를 나타내는 문장일 뿐입니다. POST는 서비스가 앞으로 어떤 컨텐츠를 포함해야 하는지(중복될 수 있음)를 나타내는 문장이지만 해당 컨텐츠를 식별하는 방법은 서버에 달려 있습니다.

PUT x(만약에x리소스 식별):"다음으로 식별된 리소스의 내용을 바꿉니다.x내 만족으로."

PUT x(만약에x파일명 "내새하고 "사용"을 합니다.x그것을 확인하기 위해."

POST x"내 컨텐츠를 저장하고 해당 컨텐츠가 포함된 리소스(이전 또는 새 컨텐츠)를 식별하는 데 사용할 수 있는 식별자를 제공합니다(다른 컨텐츠와 혼합될 수 있음)..x를 식별합니다." "y의 리소스가 x의 리소스에 종속됩니다."는 일반적으로 y를 x의 하위 경로(예: x =)로 만들어 구현할 필요는 없습니다./fooAnd y =/foo/bar) 및 x의 리소스 표현을 수정하여 새 리소스의 존재를 반영합니다(예: y의 리소스 및 일부 메타데이터에 대한 하이퍼링크 사용).REST에서 URL이 불투명하기 때문에 후자만이 좋은 디자인에 매우 중요합니다. 어쨌든 서비스를 통과하려면 클라이언트 측 URL 구성 대신 하이퍼미디어를 사용해야 합니다.

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

원본 답변(읽는 것이 더 쉬울 수 있음):

PUT /something(만약에/something 존재함 " 것은 무엇이든 가십시오.": "당신이 가지고 있는 것은 무엇이든 가져가십시오./something그리고 내가 주는 것으로 대체합니다."

PUT /something(만약에/something존재하지 않음):"내가 주는 것을 가지고 그것을 두어라./something."

POST /something"내가 주는 것을 받아서 네가 원하는 곳에 두어라,"/something작업이 끝나면 URL만 알려주시면 됩니다."

Ruby on Rails 4.0은 PUT 대신 '패치' 방법을 사용하여 부분 업데이트를 수행합니다.

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

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

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

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

POST 방법에서 신체 경보를 전송할 수 있습니다.form-data

PUT 방법에서는 바디 알람을 전송해야 합니다.x-www-form-urlencoded

머글Content-Type:application/x-www-form-urlencoded

이에 따라 PUT 방식으로는 파일이나 멀티파트 데이터를 전송할 수 없습니다.

편집

콘텐츠 유형 "application/x-www-form-urlenced"는 ASC가 아닌 이진 데이터 또는 텍스트를 대량으로 보내는 데 비효율적입니다.II 캐릭터.파일, ASCII가 아닌 데이터 및 이진 데이터가 포함된 양식을 제출할 때 "다중 부품/양식 데이터" 컨텐츠 유형을 사용해야 합니다.

그 말은 당신이 제출해야 한다면,

파일, 비 ASCII 데이터 및 이진 데이터

POST 방법을 사용해야 합니다.

이미 언급한 내용을 다시 언급하는 위험을 감수하고 PUT는 리소스를 생성할 때 클라이언트가 URL이 무엇이 될 것인지를 제어한다는 것을 의미한다는 것을 기억하는 것이 중요한 것 같습니다.따라서 PUT와 POST 중 선택할 수 있는 부분은 당신의 URL 체계가 무엇이든 상관없이 정확하고 정규화된 URL을 제공하기 위해 클라이언트를 얼마나 신뢰할 수 있는가 하는 것입니다.

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

아주 간단한 방법으로 페이스북 타임라인을 예로 들겠습니다.

사례 1: 타임라인에 무언가를 게시할 때, 그것은 새로운 항목입니다.따라서 이 경우에는 POST 방법이 동일하지 않기 때문에 POST 방법을 사용합니다.

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

사례 3: 친구가 설명을 편집할 경우, 이 경우에는 설명 ID가 있으므로 데이터베이스에 새 항목을 만드는 대신 기존 설명을 업데이트합니다.따라서 이러한 유형의 작업에는 PUT 방법이 동일하므로 PUT 방법을 사용합니다.*

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

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

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

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

기타 고려 사항:

• POST는 포함된 리소스 전체의 캐시된 복사본을 무효화합니다(일관성 향상).
• PUT 응답은 캐시할 수 없지만 POST 응답은 캐시할 수 있습니다(내용 위치 및 만료 필요).
• Java ME, 이전 브라우저, 방화벽 등에서 PUT가 덜 지원됨

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

ME에 따르면, 실제 네트워크는 신뢰할 수 없습니다.요청 시간이 초과되었습니다.연결이 재설정됩니다.네트워크는 한 번에 몇 시간 또는 며칠 동안 중단됩니다.열차는 모바일 사용자가 탑승한 터널로 들어갑니다.주어진 요청에 대해(이 모든 논의에서 가끔 인정되는 바와 같이) 요청이 도중에 물에 빠질 수도 있고, 응답이 돌아오는 도중에 물에 빠질 수도 있습니다.이러한 상황에서, 실질적인 자원에 대해 직접 PUT, POST 및 DELETE 요청을 발행하는 것은 항상 약간 잔인하고 순진하다는 인상을 받았습니다.

HTTP는 요청-응답의 안정적인 완료를 보장하는 데 아무런 도움이 되지 않으며, 네트워크 인식 응용 프로그램의 작업이기 때문에 괜찮습니다.이러한 응용 프로그램을 개발하면, 당신은 POST 대신 PUT을 사용하기 위해 후프를 건너뛰고, 중복 요청을 탐지할 경우 서버에서 특정 종류의 오류를 발생시키기 위해 더 많은 후프를 사용할 수 있습니다.클라이언트로 돌아가서 이러한 오류를 해석하고, 다시 검색하고, 다시 검증하고, 다시 게시해야 합니다.

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

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

약속과 유사한 점을 빠르게 발견할 수 있습니다. 어떤 작업을 수행하기 전에 결과에 대한 자리 표시자를 생성하고 반환합니다.또한 약속과 마찬가지로 동작은 한 번 성공하거나 실패할 수 있지만 결과는 반복적으로 가져올 수 있습니다.

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

그만큼 수많은 골치 아픈 문제들이 사라집니다.반복적인 삽입 요청은 중복 항목을 만들지 않으며, 데이터를 확보할 때까지 실제 리소스를 만들지 않습니다.(반복된 열은 분할할 수 없는 상태로 유지될 수 있습니다.)반복적인 업데이트 요청은 호환되지 않는 상태에 도달하지 않으며 이후의 변경 사항을 덮어쓰지 않습니다.고객은 어떤 이유에서든(클라이언트 충돌, 응답 누락 등) 원본 확인을 가져와 원활하게 처리할 수 있습니다.

연속적인 삭제 요청은 404 오류를 발생시키지 않고 원래 확인을 보고 처리할 수 있습니다.예상보다 시간이 오래 걸릴 경우 임시로 대응할 수 있으며, 고객이 최종 결과를 다시 확인할 수 있는 장소가 마련되어 있습니다.이 패턴의 가장 좋은 부분은 쿵푸(판다) 특성입니다.우리는 고객들이 응답을 이해하지 못할 때마다 요청을 반복하는 경향인 약점을 잡고 그것을 강점으로 바꿉니다 :-)

이것이 RESTful이 아니라고 말하기 전에 REST 원칙이 존중되는 여러 가지 방법을 고려해 보시기 바랍니다.클라이언트는 URL을 구성하지 않습니다.API는 의미론에 약간의 변화가 있더라도 검색 가능한 상태로 유지됩니다.HTTP 동사는 적절하게 사용됩니다.만약 여러분이 이것이 구현해야 할 큰 변화라고 생각한다면, 저는 경험을 통해 그렇지 않다고 말할 수 있습니다.

저장할 데이터가 방대할 것 같으면 볼륨에 대해 이야기해 보겠습니다. 일반적인 업데이트 확인은 킬로바이트의 일부입니다.HTTP는 현재 1~2분 동안 최종 응답할 수 있습니다.작업을 일주일 동안만 저장하더라도 클라이언트가 따라잡을 수 있는 충분한 기회가 있습니다.볼륨이 매우 큰 경우 전용 산 호환 키 값 저장소 또는 메모리 내 솔루션이 필요할 수 있습니다.

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)는 각각 GET 및 DELETE HTTP 메서드에 직접 매핑될 수 있습니다.그러나 C(reate) 및 U(update) 작업에 혼란이 있습니다.경우에 따라 PUT를 생성에 사용할 수 있는 반면, POST가 필요한 경우도 있습니다.모호성은 HTTP PUT 메서드 대 HTTP POST 메서드의 정의에 있습니다.

HTTP 1.1 사양에 따르면 GET, HEAD, DELETE 및 PUT 방법은 동일해야 하며 POST 방법은 동일하지 않습니다.즉, 리소스에 대해 작업을 한 번 이상 수행할 수 있고 항상 해당 리소스의 동일한 상태를 반환하는 경우 작업이 동일하다는 의미입니다.동일하지 않은 작업은 리소스의 수정된 상태를 한 요청에서 다른 요청으로 반환할 수 있습니다.따라서 비동일한 작업에서는 동일한 리소스 상태를 수신한다는 보장이 없습니다.

위의 동일한 정의에 따르면, REST 서비스에 HTTP PUT 방법을 사용하는 것과 HTTP POST 방법을 사용하는 것에 대한 나의 견해는 다음과 같습니다.다음과 같은 경우 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.

결론

REST 서비스의 경우 CRUD 작업을 HTTP 메서드와 직접 연관시키고 매핑하지 마십시오.HTTP PUT 방법과 HTTP POST 방법의 사용은 해당 작업의 동일한 측면에 기초해야 합니다.즉, 작업이 동일한 경우 HTTP PUT 방법을 사용합니다.작업이 동일하지 않으면 HTTP POST 방법을 사용합니다.

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

따라서 POST를 사용하고 리소스 생성에 PUT이 필요하지 않을 수도 있습니다.둘 다 지원할 필요는 없습니다.저는 POST로 완벽하게 충분합니다.그래서 이것은 디자인 결정입니다.

인용문에서 언급한 것처럼 IRI에 할당된 리소스가 없는 경우 PUT를 사용하여 리소스를 생성합니다.를 들면, 들면를예,PUT /users/123/password일반적으로 이전 암호를 새 암호로 대체하지만 암호가 아직 존재하지 않는 경우(예: 새로 등록한 사용자 또는 금지된 사용자 복원) 이 암호를 사용하여 암호를 만들 수 있습니다.

다음과 같이 착륙할 것입니다.

PUT는 URI에 의해 식별되는 리소스를 나타냅니다.이 경우 업데이트하는 것입니다.자원을 가리키는 세 개의 동사 중 일부입니다. 삭제하고 나머지 두 개가 됩니다.

POST는 기본적으로 '대역 외'라는 의미로 정의되는 자유 형식 메시지입니다.메시지가 디렉토리에 자원을 추가하는 것으로 해석될 수 있는 경우, 괜찮지만 기본적으로 자원에 어떤 일이 발생할지 알기 위해서는 발송(게시) 중인 메시지를 이해해야 합니다.

---

PUT, GET 및 DELETE는 리소스를 참조하므로 정의상으로도 동일합니다.

POST는 다른 세 가지 기능을 수행할 수 있지만 캐시 및 프록시와 같은 매개 변수에서 요청의 의미가 손실됩니다.게시물의 URI가 해당 게시물이 적용 중인 리소스를 반드시 나타내는 것은 아니므로 리소스에 대한 보안을 제공하는 경우에도 적용됩니다.

PUT는 생성할 필요가 없습니다. 리소스가 아직 생성되지 않은 경우 서비스에 오류가 발생할 수 있지만 그렇지 않으면 업데이트할 수 있습니다.또는 그 반대의 경우 - 자원을 작성할 수 있지만 업데이트는 허용되지 않습니다.PUT에 대해 필요한 것은 특정 리소스를 가리키고 페이로드는 해당 리소스를 나타내는 것입니다.PUT가 성공하면 GET가 동일한 리소스를 검색한다는 의미입니다(간섭 금지).

---

편집: 한 가지 더, PUT는 만들 수 있지만, 만들 경우 ID는 자연스러운 ID여야 합니다. 이메일 주소라고도 합니다.두 번 PUT할 때 두 번째 PUT은 첫 번째 PUT의 업데이트입니다.이것은 그것을 동등하게 만듭니다.

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

간단한 규칙은 다음과 같습니다.

URL에 PUT를 사용하여 해당 URL에 위치할 수 있는 리소스를 업데이트하거나 생성해야 합니다.

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

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

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

특정 URL에 리소스를 배치하면 해당 URL이나 해당 URL에 리소스가 저장됩니다.

특정 URL의 리소스에 게시할 때 해당 URL에 관련 정보를 게시하는 경우가 많습니다.이는 URL에 있는 리소스가 이미 있음을 의미합니다.

예를 들어, 새 스트림을 생성하려는 경우 이를 일부 URL에 넣을 수 있지만 기존 스트림에 메시지를 게시하려는 경우 해당 스트림의 URL에 게시합니다.

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

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

대부분의 경우 다음과 같이 사용할 수 있습니다.

• 리소스를 컬렉션에 게시합니다.
• 컬렉션/:ID로 식별된 리소스를 PUT합니다.

예:

• POST/항목
• PUT /아이템/1234

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

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

REST는 API를 단순하게 유지하기 위한 일련의 규칙 및 지침입니다."RESTFull" 상자를 확인하기 위해 복잡한 해결 방법을 사용하게 된다면 목적을 달성하지 못할 것입니다.;)

저에게 차이점을 이해하는 열쇠는 누가 리소스의 ID를 정의하는지 이해하는 것이었습니다.

예(일부 주소 서비스 포함)

POST (sever creates new resource)

client               server/addresses      // NOTE: no ID in the request
  |                                 |
  | --{POST address data}-->        |
  |                                 |
  | <--{201, created addresses/321} |      // NOTE: resource ID in the reply
  |                                 |

PUT (sever sets data of resource, creating it if necessary)

client               server/addresses/321      // NOTE: *you* put the ID here!
  |                                 |
  | --{PUT address data (to 321)}-->|
  |                                 |
  | <--{201, created }              |          // NOTE: resource ID not required here
  |                                 |

아래에 훌륭한 세부사항을 포함한 많은 훌륭한 답변들이 있지만, 그것이 요점을 파악하는 데 도움이 되었습니다.

데이터베이스 작업에 익숙하다면 다음과 같은 것들이 있습니다.

1. 선택한다.
2. 삽입
3. 갱신하다
4. 삭제
5. 병합(이미 있는 경우 업데이트, 그렇지 않은 경우 삽입)

사용합니다PUT및에는 유한작 및위사을병한및업트를 합니다.POST삽입할 경우.

요약

• 사용하다PUT대상 리소스의 상태를 요청에 포함된 표현으로 정의된 상태로 만들거나 바꿉니다.이러한 의도된 효과는 표준화되고 동일하므로 통신 장애가 발생한 경우 요청을 반복할 수 있음을 중개자에게 알립니다.
• 사용하다POST그렇지 않은 경우(대상 리소스가 아닌 다른 리소스의 상태를 만들거나 교체하는 작업 포함).의도된 효과는 표준화되지 않아 중개인이 어떤 속성도 가정할 수 없습니다.

레퍼런스

사이의 의미론적 차이에 대한 최신 권위 있는 설명POST그리고.PUT요청 방법은 RFC 9110(Roy Fielding, Mark Nottingham, Julian Reschke, 2022)에 제시되어 있습니다.

의 POST그리고.PUT메소드는 동봉된 표현에 대한 다른 의도에 의해 강조됩니다.의 대상 POST의미에 동봉된 이고, 은 자원 자체의 의미에 따라 처리하기 위한 것입니다.PUT요청은 대상 리소스의 상태를 바꾸는 것으로 정의됩니다. 따서라, 의는의의 PUT정확한 효과는 오리진 서버에서만 알 수 있지만 중간자가 볼 수 있습니다.

즉, 의의 입니다.PUT표준화(대상 자원의 상태를 요청에 동봉된 표현에 의해 정의된 상태로 만들거나 대체)하므로 모든 대상 자원에 일반적이지만, 의도된 효과는POST는 표준화되지 않았기 때문에 각 대상 리소스에 고유합니다.따라서POST의 의도된 효과를 달성하는 것을 포함하여 모든 것에 사용될 수 있습니다.PUT 방법기타 요방법청▁((방법기▁and)GET,HEAD,DELETE,CONNECT,OPTIONS,그리고.TRACE).

그러나 항상 보다 전문적인 요청 방법을 사용하는 것이 좋습니다.POST를 위해 에게 더 될 때.GET,HEAD,OPTIONS,그리고.TRACE안전한 것으로 정의됨), 통신 오류 처리(이후GET,HEAD,PUT,DELETE,OPTIONS,그리고.TRACEidempotent로 정의됨) 및 캐시 성능 최적화(이후GET그리고.HEAD캐시 가능으로 정의됨), 사용 후 POST(Roy Fielding, 2009)에서 설명한 바와 같이,

POST 다른 자원의 정보의 검색( of ). 예를 들어, 일부 자원의 표현이어야 하는 정보의 검색(GET , , , 표현의완전대체한대체(▁),▁complete▁replace한전완ment()PUT "를 바꿀 수 는 것보다 더 있는 다른 입니다.다른 메소드는 장애를 자동으로 처리할 수 있는 방법과 중간 캐시가 동작을 최적화할 수 있는 방법에 대해 설명하기 때문에 중개자에게 더욱 유용합니다. POST그런 특성을 가지고 있지는 않지만, 그렇다고 해서 우리가 그것 없이 살 수 있다는 것을 의미하지는 않습니다. POSTHTTP에서 "이 작업은 표준화할 가치가 없습니다."라는 일반적인 목적을 포함하여 많은 유용한 목적을 제공합니다.

언급URL : https://stackoverflow.com/questions/630453/what-is-the-difference-between-post-and-put-in-http