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

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

---

둘 다 본문 내부의 서버로 데이터를 보내는 것 같습니다. 그렇다면 무엇이 다른가요?

---

HTTP PUT :

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

PUT 용 HTTP 1.1 RFC 위치

HTTP POST :

POST는 데이터를 특정 URI로 보내고 해당 URI의 리소스가 요청을 처리 할 것으로 예상합니다. 이 시점에서 웹 서버는 지정된 리소스의 컨텍스트에서 데이터로 수행 할 작업을 결정할 수 있습니다. POST 메소드는 멱 등성이 아니지만 서버가 적절한 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 (영구 이동) 응답을 보내야합니다. 그러면 사용자 에이전트는 요청을 리디렉션할지 여부에 대해 자체적으로 결정할 수 있습니다.

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

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

---

의미론 만.

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

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

PUT은 파일 업로드 와 같습니다 . URI에 넣는 것은 해당 URI에 정확히 영향을줍니다. URI에 대한 POST는 어떤 영향도 미칠 수 있습니다.

---

REST 스타일 리소스의 예를 제공하려면 :

많은 책 정보가 포함 된 'POST / books'는 새 책을 만들고 해당 책을 식별하는 새 URL '/ books / 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는 일반적으로 기존 레코드가있는 경우 '대체'하고없는 경우 생성합니다.

---

1. GET : 서버에서 데이터를 가져옵니다. 다른 효과가 없어야합니다.
2. POST : 새 엔티티 생성을 위해 서버에 데이터를 보냅니다. 파일을 업로드하거나 웹 양식을 제출할 때 자주 사용됩니다.
3. PUT : POST와 비슷하지만 기존 엔티티를 대체하는 데 사용됩니다.
4. PATCH: Similar to PUT, but used to update only certain fields within an existing entity.
5. DELETE: Removes data from the server.
6. TRACE: Provides a way to test what server receives. It simply returns what was sent.
7. OPTIONS: Allows a client to get information about the request methods supported by a service. The relevant response header is Allow with supported methods. Also used in CORS as preflight request to inform server about actual request method and ask about custom headers.
8. HEAD: Returns only the response headers.
9. CONNECT: Used by browser when it knows it talks to a proxy and the final URI begins with https://. The intent of CONNECT is to allow end-to-end encrypted TLS session, so the data is unreadable to a proxy.

---

Others have already posted excellent answers, I just wanted to add that with most languages, frameworks, and use cases you'll be dealing with POST much, much more often than PUT. To the point where PUT, DELETE, etc. are basically trivia questions.

---

A POST is considered something of a factory type method. You include data with it to create what you want and whatever is on the other end knows what to do with it. A PUT is used to update existing data at a given URL, or to create something new when you know what the URI is going to be and it doesn't already exist (as opposed to a POST which will create something and return a URL to it if necessary).

---

Please see: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

I’ve been getting pretty annoyed lately by a popular misconception by web developers that a POST is used to create a resource, and a PUT is used to update/change one.

If you take a look at page 55 of RFC 2616 (“Hypertext Transfer Protocol – HTTP/1.1”), Section 9.6 (“PUT”), you’ll see what PUT is actually for:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

There’s also a handy paragraph to explain the difference between POST and PUT:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request – the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.

It doesn’t mention anything about the difference between updating/creating, because that’s not what it’s about. It’s about the difference between this:

obj.set_attribute(value) # A POST request.

And this:

obj.attribute = value # A PUT request.

So please, stop the spread of this popular misconception. Read your RFCs.

---

REST asks developers to use HTTP methods explicitly and in a way that's consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:

• To create a resource on the server, use POST.

• To retrieve a resource, use GET.

• To change the state of a resource or to update it, use PUT.

• To remove or delete a resource, use DELETE.

More info: RESTful Web services: The basics from IBM

---

The difference between POST and PUT is that PUT is idempotent, that means, calling the same PUT request multiple times will always produce the same result(that is no side effect), while on the other hand, calling a POST request repeatedly may have (additional) side effects of creating the same resource multiple times.

GET : Requests using GET only retrieve data , that is it requests a representation of the specified resource

POST : It sends data to the server to create a resource. The type of the body of the request is indicated by the Content-Type header. It often causes a change in state or side effects on the server

PUT : Creates a new resource or replaces a representation of the target resource with the request payload

PATCH : It is used to apply partial modifications to a resource

DELETE : It deletes the specified resource

TRACE : It performs a message loop-back test along the path to the target resource, providing a useful debugging mechanism

OPTIONS : It is used to describe the communication options for the target resource, the client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server.

HEAD : It asks for a response identical to that of a GET request, but without the response body

CONNECT : It establishes a tunnel to the server identified by the target resource , can be used to access websites that use SSL (HTTPS)

---

It would be worth mentioning that POST is subject to some common CSRF attacks while PUT isn't.

The CSRF below are not possible with PUT when the victim visits attackersite.com:

Normal request (cookies are sent): (PUT is not a supported attribute value)

<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 request (cookies are sent): (PUT would trigger a preflight request)

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

---

REST-ful usage

POST is used to create a new resource and then returns the resource URI

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

This call may create a new book and returns that book URI

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

PUT is used to replace a resource, if that resource is exist then simply update it, but if that resource doesn't exist then create it,

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

With PUT we know the resource identifier, but POST will return the new resource identifier

Non REST-ful usage

POST is used to initiate an action on the server side, this action may or may not create a resource, but this action will have side affects always it will change something on the server

PUT is used to place or replace literal content at a specific URL

Another difference in both REST-ful and non REST-ful styles

POST is Non-Idempotent Operation: It will cause some changes if executed multiple times with the same request.

PUT is Idempotent Operation: It will have no side-effects if executed multiple times with the same request.

참고URL : https://stackoverflow.com/questions/107390/whats-the-difference-between-a-post-and-a-put-http-request