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

StackOverflow https://stackoverflow.com/questions/107390

  •  01-07-2019
  •  | 
  •  

문제

둘 다 몸 안의 서버로 데이터를 보내는 것 같은데, 무엇이 다른가요?

도움이 되었습니까?

해결책

HTTP 넣기:

PUT은 파일이나 리소스를 특정 URI에, 정확히 해당 URI에 넣습니다.해당 URI에 이미 파일이나 리소스가 있는 경우 PUT은 해당 파일이나 리소스를 대체합니다.거기에 파일이나 리소스가 없으면 PUT이 파일이나 리소스를 생성합니다.PUT은 멱등성, 하지만 역설적이게도 PUT 응답은 캐시할 수 없습니다.

PUT에 대한 HTTP 1.1 RFC 위치

HTTP 포스트:

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

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

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

POST용 HTTP 1.1 RFC 위치

POST와 PUT의 차이점:

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

게시물과 PUT 요청의 기본 차이는 요청 -URI의 다른 의미에 반영됩니다.포스트 요청의 URI는 동봉 된 엔티티를 처리 할 리소스를 식별합니다.이 리소스는 데이터 수용 프로세스, 다른 프로토콜의 관문 또는 주석을 받아들이는 별도의 엔티티 일 수 있습니다.반대로, PUT 요청의 URI는 요청과 함께 동봉 된 엔티티를 식별합니다. 사용자 에이전트는 URI의 의도가 무엇인지 알고 서버가 다른 리소스에 요청을 적용하지 않아야합니다.서버가 요청이 다른 URI에 적용되기를 원하는 경우 301 (영구적으로 이동) 응답을 보내야합니다.그런 다음 사용자 에이전트는 요청을 리디렉션할지 여부에 대해 자체 결정을 내릴 수 있습니다.

관련 없는 올바른 방법을 사용하여:

한 가지 이점 나머지 ROA SOAP와 비교하면 HTTP REST ROA를 사용할 때 HTTP 동사/메서드의 적절한 사용을 권장한다는 것입니다.예를 들어 정확한 위치에 리소스를 생성하려는 경우에만 PUT을 사용합니다.그리고 리소스를 생성하거나 수정하는 데 GET을 사용하지 않을 것입니다.

다른 팁

의미론 만.

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

HTTP POST 더 일반적입니다.서버에서 작업을 시작해야 합니다.해당 작업은 URI로 식별된 리소스에 요청 본문을 저장하는 것일 수도 있고, 다른 URI이거나 다른 작업일 수도 있습니다.

PUT은 좋다 파일 업로드.URI에 넣으면 해당 URI에 정확히 영향을 미칩니다.URI에 대한 POST는 어떤 영향을 미칠 수 있습니다.

REST 스타일 리소스의 예를 제공하려면 다음을 수행하세요.

여러 책 정보가 포함된 "POST /books"는 새 책을 생성하고 해당 책을 식별하는 새 URL로 응답할 수 있습니다."/책/5".

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

비리소스 스타일에서 POST는 부작용이 있는 모든 것에 사용될 수 있습니다.또 다른 차이점 중 하나는 PUT이 멱등적이어야 한다는 것입니다. 동일한 URL에 대한 동일한 데이터의 여러 PUT은 괜찮지만, 여러 POST는 여러 개체를 생성하거나 POST 작업이 수행하는 모든 작업을 수행할 수 있습니다.

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

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

인용하다 HTTP RFC

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

  1. POST - 문서 또는 기타 리소스를 생성하려면

  2. PUT - 생성된 문서 또는 기타 리소스를 업데이트합니다.

그러나 PUT에 대해 명확하게 말하면 일반적으로 기존 레코드가 있으면 '교체'하고 없으면 생성합니다.

다른 사람들은 이미 훌륭한 답변을 게시했습니다. 저는 대부분의 언어, 프레임워크 및 사용 사례에서 PUT보다 훨씬 더 자주 POST를 처리하게 될 것이라는 점을 추가하고 싶었습니다.PUT, DELETE 등이 있는 지점까지기본적으로 퀴즈 질문입니다.

  1. 얻다:서버에서 데이터를 검색합니다.다른 효과가 없어야 합니다.
  2. 우편:새 엔터티를 생성하기 위해 서버에 데이터를 보냅니다.파일을 업로드하거나 웹 양식을 제출할 때 자주 사용됩니다.
  3. 놓다:POST와 유사하지만 기존 엔터티를 대체하는 데 사용됩니다.
  4. 반점:PUT과 유사하지만 기존 엔터티 내의 특정 필드만 업데이트하는 데 사용됩니다.
  5. 삭제:서버에서 데이터를 제거합니다.
  6. 추적하다:서버가 수신하는 것을 테스트하는 방법을 제공합니다.단순히 보낸 내용을 반환합니다.
  7. 옵션:클라이언트가 서비스에서 지원하는 요청 방법에 대한 정보를 얻을 수 있도록 합니다.관련 응답 헤더는 지원되는 방법이 있는 허용입니다.또한 CORS에서 서버에 실제 요청 방법을 알리고 사용자 정의 헤더에 대해 물어보기 위한 실행 전 요청으로 사용됩니다.
  8. 머리:응답 헤더만 반환합니다.
  9. 연결하다:브라우저가 프록시와 통신하고 최종 URI가 https://로 시작한다는 것을 알고 있을 때 브라우저에서 사용됩니다.CONNECT의 목적은 종단간 암호화된 TLS 세션을 허용하여 프록시가 데이터를 읽을 수 없도록 하는 것입니다.

POST는 팩토리 유형 메소드로 간주됩니다.원하는 것을 생성하기 위해 데이터를 포함하면 상대방이 무엇을 해야 할지 알 수 있습니다.PUT는 주어진 URL에서 기존 데이터를 업데이트하는 데 사용됩니다. 또는 URI가 무엇인지 알지만 아직 존재하지 않는 경우 새로운 것을 생성하는 데 사용됩니다(무언가를 생성하고 URL을 반환하는 POST와 반대). 필요한 경우).

다음을 참조하세요: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

나는 최근에 POST가 리소스를 생성하는 데 사용되고 PUT가 리소스를 업데이트/변경하는 데 사용된다는 웹 개발자들의 대중적인 오해 때문에 꽤 짜증이 났습니다.

RFC 2616(“Hypertext Transfer Protocol – HTTP/1.1”)의 55페이지를 살펴보면, 섹션 9.6 (“PUT”) 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를 읽어보세요.

REST는 개발자에게 프로토콜 정의와 일치하는 방식으로 HTTP 방법을 명시 적으로 사용하도록 요청합니다.이 기본 REST 설계 원칙은 CRUD (Create, Read, Update 및 Delete) 작업과 HTTP 방법간에 일대일 매핑을 설정합니다.이 매핑에 따르면 :

• 서버에 리소스를 생성하려면 POST를 사용합니다.

• 리소스를 검색하려면 GET을 사용합니다.

• 리소스 상태를 변경하거나 업데이트하려면 PUT을 사용합니다.

• 리소스를 제거하거나 삭제하려면 DELETE를 사용합니다.

더 많은 정보:RESTful 웹 서비스:IBM의 기본 사항

POST와 PUT의 차이점은 PUT가 멱등하다는 것입니다. 즉, 동일한 PUT 요청을 여러 번 호출하면 항상 동일한 결과가 생성되지만(부작용 없음), 반면에 POST 요청을 반복적으로 호출하면 다음과 같은 결과가 발생할 수 있습니다. 추가) 동일한 리소스를 여러 번 생성하면 부작용이 발생합니다.

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

POST :리소스를 생성하기 위해 서버에 데이터를 보냅니다.요청 본문 유형은 Content-Type 헤더로 표시됩니다.서버의 상태 변화나 부작용을 일으키는 경우가 많습니다.

PUT :새 리소스를 생성하거나 대상 리소스의 표현을 요청 페이로드로 바꿉니다.

PATCH :리소스에 부분 수정을 적용하는 데 사용됩니다.

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

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

OPTIONS :이는 대상 리소스에 대한 통신 옵션을 설명하는 데 사용되며, 클라이언트는 OPTIONS 메서드에 대한 URL을 지정하거나 전체 서버를 참조하기 위해 별표(*)를 지정할 수 있습니다.

HEAD :GET 요청과 동일한 응답을 요청하지만 응답 본문은 없습니다.

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

그것을 언급할 가치가 있을 것입니다 POST 몇 가지 공통 사항이 적용됩니다. CSRF 공격 ~하는 동안 PUT 그렇지 않습니다.

아래 CSRF는 불가능하다 PUT 피해자가 공격자 사이트.com을 방문할 때:

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

<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 비행 전 요청을 트리거합니다) 

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

간단히

POST 리소스를 생성하는 데 사용되며 리소스를 반환합니다. URI전 

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

이 호출은 새 책을 생성하고 해당 책을 반환해야 합니다. URI

Response ..../books/5

PUT 리소스를 교체하는 데 사용됩니다. 해당 리소스가 존재하면 간단히 업데이트하고 해당 리소스가 존재하지 않으면 생성합니다. 

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

사용하여 PUT 우리는 리소스 식별자를 제공하지만 POST 새로운 리소스 식별자를 반환합니다

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top