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

답변:

893

HTTP PUT :

PUT은 파일 또는 리소스를 특정 URI에 정확하게 해당 URI에 넣습니다. 해당 URI에 파일이나 리소스가 이미 있으면 PUT은 해당 파일이나 리소스를 대체합니다. 파일이나 리소스가 없으면 PUT에서 파일이나 리소스를 만듭니다. PUT은 dem 등원 이지만 역설적으로 PUT 응답은 캐시 할 수 없습니다.

PUT의 HTTP 1.1 RFC 위치

HTTP POST :

POST는 데이터를 특정 URI로 보내고 해당 URI의 리소스가 요청을 처리 할 것으로 예상합니다. 이 시점에서 웹 서버는 지정된 자원의 컨텍스트에서 데이터로 수행 할 작업을 결정할 수 있습니다. POST 메소드는 idempotent 가 아니지만 서버가 적절한 Cache-Control 및 Expires 헤더를 설정하는 한 POST 응답 은 캐시 가능합니다.

공식 HTTP RFC는 POST를 다음과 같이 지정합니다.

  • 기존 자원의 주석
  • 게시판, 뉴스 그룹, 메일 링리스트 또는 유사한 기사 그룹에 메시지 게시;
  • 양식 제출 결과와 같은 데이터 블록을 데이터 처리 프로세스에 제공하는 단계;
  • 추가 작업을 통해 데이터베이스를 확장합니다.

POST의 HTTP 1.1 RFC 위치

POST와 PUT의 차이점 :

RFC 자체는 핵심 차이점을 설명합니다.

POST와 PUT 요청의 근본적인 차이점은 Request-URI의 다른 의미에 반영됩니다. POST 요청의 URI는 동봉 된 엔터티를 처리 할 리소스를 식별합니다. 해당 리소스는 데이터 수락 프로세스, 다른 프로토콜의 게이트웨이 또는 주석을 허용하는 별도의 엔터티 일 수 있습니다. 반대로 PUT 요청의 URI는 요청으로 둘러싸인 엔티티를 식별합니다. 사용자 에이전트는 어떤 URI가 의도되어 있는지 알고 서버는 요청을 다른 자원에 적용해서는 안됩니다. 서버가 요청을 다른 URI에 적용하려면 301 (영구적으로 이동) 응답을 보내야합니다. 그런 다음 사용자 에이전트는 요청을 리디렉션할지 여부에 대한 자체 결정을 내릴 수 있습니다.

또한 RFC 7231 섹션 4.3.4 PUT 상태 (강조 추가)

4.3.4. 놓다

PUT 메소드는 대상 자원 의 상태가 요청 메시지 페이로드에 포함 된 표시에 의해 정의 된 상태 created또는 replaced상태가되도록 요청합니다.

적절한 방법을 사용하면 관련이 없습니다.

REST ROA 와 SOAP의 장점 중 하나 는 HTTP REST ROA를 사용할 때 HTTP 동사 / 방법의 올바른 사용을 장려한다는 것입니다. 예를 들어 정확한 위치에 리소스를 만들려는 경우에만 PUT을 사용합니다. 그리고 GET을 사용하여 리소스를 만들거나 수정하지 않습니다.

— 브라이언 알 본디
소스
1
나는 사양에서 읽었습니다 If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. 존재하지 않는 경우 리소스 생성을 거부하는 PUT의 구현이 맞습니까? 그렇다면 실제로 이런 일이 발생합니까? 아니면 구현은 일반적으로 PUT에서도 생성됩니까?
— houcros 2012 년
1
차이점을 분명히하는 몇 가지 추가 예외는 다음 URL에 있습니다. dzone.com/articles/put-vs-post
— Ashish Shetkar
1
내가 이해하지 못하는 것은 PUT의 dem 등원을 구현하는 방법입니다. 일반적으로 대부분의 API는 새 리소스를 생성 할 때 ID 자동 생성을 사용합니다. PUT에서는 리소스가 존재하지 않으면 리소스를 만들어야하지만 URI에 지정된 ID를 사용해야하지만 id 생성 방법이 자동으로 설정된 경우 어떻게 할 수 있습니까 ???
— Roni Axelrad
1
간단히 말해 : POST 요청 의 URI 는 동봉 된 엔터티를 처리 할 리소스를 식별 합니다 . PUT 요청 의 URI 는 엔티티 자체를 식별 합니다 .
— Drazen Bjelovuk
POST 방법에 대한 응답은 캐시 할 수 없습니다. 응답에 적절한 Cache-Control 또는 Expires 헤더 필드가 포함되어 있지 않는 한
— NattyC
211

의미론 만.

HTTP PUT는 요청 본문을 수락 한 다음 URI로 식별 된 리소스에 저장해야합니다.

HTTP POST가 더 일반적입니다. 서버에서 작업을 시작해야합니다. 이 조치는 요청 본문을 URI로 식별 된 자원에 저장하거나 다른 URI이거나 다른 조치 일 수 있습니다.

PUT은 파일 업로드 와 같습니다 . URI에 넣는 것은 해당 URI에 정확히 영향을줍니다. URI에 대한 POST는 전혀 영향을 미치지 않습니다.

— 조나단 아켈
소스
특정 기능을 암시하는 것은 실제로는 그렇지 않을 수도 있습니다
— TaylorMac
131

REST 스타일 자원의 예를 제공하려면 다음을 수행하십시오.

많은 책 정보가 포함 된 "POST / books"는 새로운 책을 만들고 해당 책을 식별하는 새로운 URL로 응답합니다 : "/ books / 5".

"PUT / books / 5"는 id가 5 인 새 책을 만들거나 기존 책을 ID 5로 바꿔야합니다.

비자 원 스타일에서 POST는 부작용이있는 모든 것에 사용될 수 있습니다. 또 다른 차이점은 PUT은 dem 등원이어야한다는 것입니다. 여러 개의 POST가 여러 개의 오브젝트를 작성하거나 POST 조치가 수행하는 모든 작업을 수행 할 수 있지만 동일한 URL에 동일한 데이터의 여러 PUT은 양호해야합니다.

— 보홀리스
소스
안녕하세요 Bhollis, POST / books / 5를 사용하면 어떻게됩니까? 자원을 찾을 수 없습니까?
— ChanGan
13
나는 dem 등성이 PUT과 POST의 가장 구별되고 중요한 차이점이라고 생각합니다
— Martin Andersson
1
안녕하세요 ChanGan, Wikipedia에서 "POST / books / 5"사례에 대해 설명합니다. "일반적으로 사용되지 않습니다. 주소가 지정된 멤버를 자체적으로 컬렉션으로 취급하고 새 항목을 만듭니다."
— rdiachenko
이 답변은 PUT과 POST가 동일한 리소스에서 정의 될 수 있다는 인상을 주지만 dem 등원 옆의 다른 차이점은 누가 ID 공간을 제어하는지입니다. PUT에서 사용자는 특정 ID로 자원을 작성하여 ID 공간을 제어합니다. POST에서 서버는 사용자가 GET과 같은 후속 호출에서 참조 해야하는 ID를 반환합니다. 위의 두 가지가 혼합되어 있기 때문에 이상합니다.
— 토미
74
  1. GET : 서버에서 데이터를 검색합니다. 다른 효과가 없어야합니다.
  2. POST : 새 엔티티를 작성하기 위해 서버로 데이터를 보냅니다. 파일을 업로드하거나 웹 양식을 제출할 때 종종 사용됩니다.
  3. PUT : POST와 유사하지만 기존 엔티티를 대체하는 데 사용됩니다.
  4. PATCH : PUT과 유사하지만 기존 엔터티 내의 특정 필드 만 업데이트하는 데 사용됩니다.
  5. DELETE : 서버에서 데이터를 제거합니다.
  6. TRACE : 서버가받는 것을 테스트하는 방법을 제공합니다. 보낸 내용 만 반환합니다.
  7. 옵션 : 클라이언트가 서비스가 지원하는 요청 방법에 대한 정보를 얻을 수 있습니다. 관련 응답 헤더는 지원되는 메소드 허용입니다. 또한 CORS에서 프리 플라이트 요청으로 사용되어 서버에 실제 요청 방법을 알리고 사용자 지정 헤더에 대해 묻습니다.
  8. HEAD : 응답 헤더 만 반환합니다.
  9. CONNECT : 브라우저가 프록시와 통신하고 최종 URI가 https : //로 시작하는 것을 알고있을 때 브라우저에서 사용합니다. CONNECT의 의도는 엔드 투 엔드 암호화 된 TLS 세션을 허용하여 데이터를 프록시에서 읽을 수 없도록하는 것입니다.
— 조 나탄 드래곤
소스
9
가장 짧은 대답
— vibs2006
https를 사용할 때 각 요청 전에 CONNECT가 발생합니까?
— 변수
66

PUT은 특정 URI에 항목을 "업로드"하거나 해당 URI에 이미있는 내용을 덮어 쓰는 방법입니다.

반면에 POST는 주어진 URI에 관련 데이터를 제출하는 방법입니다.

HTTP RFC를 참조하십시오

— 다니엘 브루스
소스
45

내가 아는 한 PUT은 주로 레코드를 업데이트하는 데 사용됩니다.

  1. POST-문서 또는 기타 리소스를 만들려면

  2. PUT-작성된 문서 또는 기타 자원을 업데이트합니다.

그러나 PUT은 일반적으로 기존 레코드가있는 경우 기존 레코드를 '대체'하고 존재하지 않는 경우 작성합니다.

— 찬간
소스
1
이 맥락에서 기록은 무엇입니까? 문제는 HTTP 요청에 관한 것입니다.
— Kishore
문서 / 자원이 이미 존재하는 경우 POST는 어떻게합니까? 오류가 발생합니까, 아니면 그냥 꺼 집니까?
— Aditya Pednekar
내가 읽은 대부분의 내용을 기반으로 PUT도 만들 수 있습니다.
— aderchox
19

다른 사람들은 이미 훌륭한 답변을 게시했습니다 .POST보다 훨씬 자주 POST를 다루는 대부분의 언어, 프레임 워크 및 사용 사례를 추가하고 싶었습니다. PUT, DELETE 등이 기본적으로 사소한 질문입니다.

— 제이슨 모리슨
소스
15

다음을 참조하십시오 : http://zacharyvoase.com/2009/07/03/http-post-put-diff/

웹 개발자가 POST를 사용하여 리소스를 만드는 데 사용되고 PUT을 사용하여 리소스를 업데이트 / 변경하는 데 대한 대중의 오해로 인해 최근 화가났습니다.

RFC 2616 ( "하이퍼 텍스트 전송 프로토콜 – HTTP / 1.1") 섹션 9.6 ( "PUT") 55 페이지를 보면 PUT의 실제 내용을 확인할 수 있습니다.

PUT 메소드는 동봉 된 엔티티가 제공된 Request-URI 아래에 저장되도록 요청합니다.

POST와 PUT의 차이점을 설명하는 편리한 단락도 있습니다.

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

업데이트 / 생성의 차이점에 대해서는 언급하지 않았습니다. 왜냐하면 그것이 중요하지 않기 때문입니다. 이것의 차이점에 관한 것입니다.

obj.set_attribute(value) # A POST request.

이:

obj.attribute = value # A PUT request.

따라서이 대중적인 오해의 확산을 멈추십시오. RFC를 읽으십시오.

— 나 지불 하산
소스
13
이것은 무의미하고 무례한 것처럼 보이지 않습니다. 인용 한 PUT의 예에서, 새로운 엔티티는 RESTful API에서 '새로운'레코드이며 해당 위치에서 액세스 할 수 있습니다. 하위 멤버를 변경하는 것이 좋은 디자인 선택인지 여부에 의문의 여지가 있지만 (이상적이지 않다고 생각합니다), 심지어 하위 종을 사용하여 많은 유용한 정보를 공격하고 있습니다. 대부분의 경우, 일반적으로 언급되는 설명은 요약 된 RFC의 내용과 일반적인 관습 및 관습에 대한 진술입니다. 또한 공손하게 해치지 않습니다.
— tooluser
3
이것은 충분히 공감 될 수 없습니다. REST API에는 PUT이 없습니다. 대부분의 경우 POST는 올바른 의미를 나타냅니다.
— Beefster
잘 말하지 않았지만 실제로 RFC를 정확하게 해석했습니다. 웹 개발자 세계는 잘못된 정보의 늪입니다.
— 윌리엄 T Froggard
@Beefster 'POST 표시'와 같은 것은 없습니다. Najeebul은 여기서 큰 지적을했습니다. 그것이 무엇을 나타내는 지 어떻게 알 수 있습니까? 당신이 그것을 배운 첫날부터 항상 그런 식으로 사용했기 때문에 그것을 사용한다는 것을 제외하고는 왜 다른 것에 비해 그것을 사용해야하는지 정말로 모르십니까?
— Mosia Thabo
12

POST는 팩토리 유형의 방법으로 간주됩니다. 당신은 당신이 원하는 것을 만들기 위해 데이터를 포함하고 다른 한편으로는 무엇을 해야할지 알고 있습니다. PUT은 주어진 URL에서 기존 데이터를 업데이트하거나 URI가 무엇인지 알고 있고 이미 존재하지 않을 때 새로운 것을 만드는 데 사용됩니다 (POST와는 달리 무언가를 만들고 URL을 필요한 경우).

— 사용자
소스
10

REST는 개발자에게 HTTP 메소드를 명시 적으로 그리고 프로토콜 정의와 일치하는 방식으로 사용하도록 요청합니다. 이 기본 REST 설계 원칙은 CRUD (작성, 읽기, 업데이트 및 삭제) 조작과 HTTP 메소드간에 일대일 맵핑을 설정합니다. 이 매핑에 따르면 :

• 서버에서 리소스를 만들려면 POST를 사용하십시오.

• 리소스를 검색하려면 GET을 사용하십시오.

• 자원 상태를 변경하거나 업데이트하려면 PUT을 사용하십시오.

• 리소스를 제거하거나 삭제하려면 DELETE를 사용하십시오.

추가 정보 : RESTful 웹 서비스 : IBM의 기본 사항

— 긴 응 우옌
소스
나는 당신이 PUT과 POST를 거꾸로 가지고 있다고 생각합니다
— Beefster
@Beefster Post to create, 업데이트를 하시겠습니까?
— Long Nguyen
아니요. PUT은 실제로 리터럴 컨텐츠를 URL에 배치하기위한 것으로 REST API에 거의 포함되지 않습니다. POST는보다 추상적이고 "이 정확한 파일을이 정확한 URL에 넣습니다"라는 의미가없는 모든 종류의 컨텐츠를 추가합니다.
— Beefster
7

하나 또는 다른 것을 사용할 때는 매우 간단해야하지만 복잡한 표현은 많은 사람들에게 혼란의 원천입니다.

사용시기 :

  • PUT이미 자원 콜렉션의 일부인 단일 자원을 수정하려는 경우에 사용하십시오 . PUT자원을 완전히 대체합니다. 예:PUT /resources/:resourceId

    참고 :PATCH 리소스의 일부를 업데이트하려는 경우 사용하십시오 .

  • POST자원 콜렉션 아래에 하위 자원을 추가하려는 경우에 사용하십시오 .
    예:POST => /resources

일반적으로 :

  • 일반적으로, 실제로, 항상 사용 PUT에 대한 업데이트 작업.
  • 항상 사용 POST에 대한 CREATE 작업을.

예:

GET / company / reports => 모든 보고서 가져 오기
GET / company / reports / {id} => "id"로 식별 된 보고서 정보 가져 오기
POST / company / reports => 새 보고서 작성
PUT / company / reports / {id} => 업데이트 "id"로 식별 된 보고서 정보
PATCH / company / reports / {id} => "id"로 식별 된 보고서 정보의 일부 업데이트
DELETE / company / reports / {id} => "id"로 보고서 삭제

— Dzenis H.
소스
4

POST와 PUT의 차이점은 PUT이 dem 등 적이라는 것입니다. 즉, 동일한 PUT 요청을 여러 번 호출하면 항상 동일한 결과가 발생하지만 (부작용이 아님), 반면 POST 요청을 반복해서 호출하면 ( 추가) 동일한 자원을 여러 번 작성하는 부작용.

GET : GET을 사용하는 요청은 데이터 만 검색합니다. 즉, 지정된 자원의 표현을 요청합니다.

POST: 서버로 데이터를 보내서 리소스를 만듭니다. 요청 본문의 유형은 Content-Type 헤더로 표시됩니다. 종종 서버의 상태 또는 부작용이 변경됩니다

PUT : 새 자원을 작성하거나 대상 자원의 표현을 요청 페이로드로 바꿉니다.

PATCH : 자원에 부분 수정을 적용하는 데 사용됩니다.

DELETE : 지정된 리소스를 삭제합니다

TRACE : 대상 리소스의 경로를 따라 메시지 루프백 테스트를 수행하여 유용한 디버깅 메커니즘을 제공합니다.

OPTIONS : 대상 자원의 통신 옵션을 설명하는 데 사용되며 클라이언트는 OPTIONS 메소드의 URL을 지정하거나 전체 서버를 나타내는 별표 (*)를 지정할 수 있습니다.

HEAD : GET 요청과 동일하지만 응답 본문이없는 응답을 요청합니다.

CONNECT : 대상 리소스로 식별되는 서버에 터널을 설정하고 SSL (HTTPS)을 사용하는 웹 사이트에 액세스하는 데 사용할 수 있습니다

— irfan
소스
2

REST-ful 사용법

POST 새 리소스를 만든 다음 리소스를 반환하는 데 사용됩니다 URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

이 전화는 새 책을 만들어 그 책을 반환 할 수 있습니다 URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT 리소스를 교체하는 데 사용됩니다. 해당 리소스가있는 경우 간단히 업데이트하지만 해당 리소스가없는 경우 리소스를 만들고 

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

함께 PUT우리 자원 ID를 알고 있지만, POST새로운 리소스 식별자를 반환합니다

REST가 아닌 사용량

POST 서버 측에서 작업을 시작하는 데 사용됩니다.이 작업은 리소스를 생성하거나 생성하지 않을 수 있지만이 작업은 항상 서버에 무언가 변경 될 수있는 부작용이 있습니다.

PUT 특정 URL에 리터럴 컨텐츠를 배치하거나 바꾸는 데 사용됩니다.

REST-ful과 비 REST-ful 스타일의 또 다른 차이점

POST 비등 전성 작동 : 동일한 요청으로 여러 번 실행될 경우 일부 변경이 발생합니다.

PUT Idempotent Operation : 동일한 요청으로 여러 번 실행될 경우 부작용이 없습니다.

— 멜라 드 바실리 우스
소스
1

POST일반적인 CSRF (Cross-Site Request Forgery) 공격이 적용 되는 PUT것은 아니지만 언급 할 가치가 있습니다 .

피해자가 방문 할 때는 아래 CSRF를 사용할 수 없습니다PUTattackersite.com .

공격의 효과는 것입니다 피해자가 실수로 사용자 삭제 그 (피해자가) 로그인에 한해서로 admin에를 target.site.com방문하기 전에 attackersite.com:

일반 요청 (쿠키가 전송 됨) : ( PUT지원되는 속성 값이 아님)

코드 attackersite.com:

<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

XHR 요청 (쿠키가 전송 됨) : ( PUT프리 플라이트 요청을 트리거하여 브라우저에서 deleteUser페이지 를 요청하지 못하게 함 )

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
— 마리노스 안
소스
1

간단한 단어로 말할 수 있습니다.

1. HTTP Get : 하나 이상의 항목을 가져 오는 데 사용됩니다

2.HTTP Post : 항목을 만드는 데 사용됩니다

3. HTTP Put : 항목을 업데이트하는 데 사용됩니다

4. HTTP 패치 : 항목을 부분적으로 업데이트하는 데 사용됩니다

5. HTTP 삭제 : 항목을 삭제하는 데 사용됩니다

— 프라 테쿠 굽타
소스
0

실제로 제목 외에는 차이가 없습니다. 실제로 GET과 다른 것 사이에는 기본적인 차이점이 있습니다. "GET"-Request 메소드를 사용하면 url-address-line으로 데이터를 보내며, 먼저 물음표로 구분되고 & 기호로 구분됩니다.

그러나 "POST"요청 방법을 사용하면 URL을 통해 데이터를 전달할 수 없지만 요청의 소위 "본문"에서 데이터를 개체로 전달해야합니다. 서버 측에서는 전송 된 데이터를 얻기 위해 수신 된 컨텐츠의 본문을 읽어야합니다. 그러나 다른 한편으로는 "GET"-요청을 보낼 때 본문에 내용을 보낼 가능성이 없습니다.

"GET"은 데이터를 가져 오기위한 것이며 "POST"는 데이터를 게시하기위한 것입니다. "GET"요청 또는 "POST"요청에 의해 전송 된 데이터를 기반으로 새 컨텐츠를 작성하거나 기존 컨텐츠를 삭제하거나 기존 컨텐츠를 편집하거나 백엔드에서 무엇이든 할 수 없습니다. "POST"-Request로 클라이언트가 데이터를 요청하는 방식으로 백엔드를 코딩하는 것을 막을 수있는 사람은 아무도 없습니다.

어떤 방법을 사용하든 요청에 ​​따라 URL을 호출하고 지정할 데이터를 보내거나 보내지 않고 요청을 처리하기 위해 서버로 전달할 정보를 보낸 다음 클라이언트가 응답을받습니다. 서버. 데이터에는 보내려는 모든 것이 포함될 수 있으며 백엔드는 데이터로 원하는 모든 것을 할 수 있으며 응답에는 거기에 넣고 싶은 정보가 포함될 수 있습니다.

이 두 가지 기본 방법 만 있습니다. GET 및 POST. 그러나 그것은 그들의 구조이기 때문에 백엔드에서 코딩하는 것과 다르고 다릅니다. 백엔드에서는 수신 된 데이터를 사용하여 원하는 것을 코딩 할 수 있습니다. 그러나 "POST"-요청을 사용하면 url-addressline이 아닌 본문에서 데이터를 보내거나 검색해야하며 "GET"요청을 사용하면 url-addressline이 아닌 url-addressline에서 데이터를 보내거나 검색해야합니다. 몸. 그게 다야.

"PUT", "DELETE"등과 같은 다른 모든 메소드는 "POST"와 동일한 구조를 갖습니다.

url-addressline에 쓰는 내용이 캐시에 저장되고 GET-Method는 데이터로 url-addressline을 작성하는 것과 동일하기 때문에 내용을 다소 숨기려면 POST 방법이 주로 사용됩니다. 따라서 항상 사용자 이름 및 비밀번호가 아닌 민감한 데이터를 보내려면 url-address-line에 표시하지 않으려는 일부 ID 또는 해시와 같이 POST 메소드를 사용해야합니다 .

또한 URL- 주소 줄의 길이는 1024 기호로 제한되는 반면 "POST"-방법은 제한되지 않습니다. 따라서 더 많은 양의 데이터가있는 경우 GET-Request와 함께 보낼 수는 없지만 POST-Request를 사용해야합니다. 따라서 이것은 POST 요청의 또 다른 장점입니다.

그러나 복잡한 텍스트를 보내지 않으면 GET 요청을 처리하는 것이 훨씬 쉽습니다. 그렇지 않으면 POST 방법의 또 다른 장점은 GET 방법을 사용하면 텍스트 또는 공백 내에서 일부 기호를 보낼 수 있도록 텍스트를 URL 인코딩해야한다는 것입니다. 그러나 POST 방법을 사용하면 제한이 없으며 내용을 변경하거나 조작 할 필요가 없습니다.

— 하아
소스
0

PUT과 POST는 모두 Rest Methods입니다.

PUT-동일한 매개 변수를 두 번 사용하여 PUT을 사용하여 동일한 요청을 두 번하는 경우 두 번째 요청은 영향을 미치지 않습니다. 그렇기 때문에 PUT이 일반적으로 업데이트 시나리오에 사용되는 이유는 동일한 매개 변수로 Update를 두 번 이상 호출하면 초기 호출보다 더 많은 작업을 수행하지 않으므로 PUT이 dem 등원입니다.

POST는 idempotent가 아닙니다. 예를 들어 Create는 대상에 두 개의 개별 항목을 작성하므로 idempotent가 아니므로 CREATE는 POST에서 널리 사용됩니다.

매번 동일한 매개 변수로 POST를 사용하여 동일한 호출을 수행하면 두 가지 다른 상황이 발생하므로 POST가 작성 시나리오에 일반적으로 사용되는 이유

— 카르 틱 카 수바
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.