PUT과 POST – 차이점

PUT과 POST의 주요 차이점

  • PUT 메소드는 단일 리소스를 수정해야 할 때 호출되고, POST 메소드는 하위 리소스를 추가해야 할 때 호출됩니다.
  • POST 메서드 응답은 캐시할 수 있지만 PUT 메서드 응답은 캐시할 수 없습니다.
  • PUT에서는 UPDATE 쿼리를 사용할 수 있고, POST에서는 쿼리 생성을 사용할 수 있습니다.
  • PUT 방식에서는 클라이언트가 어떤 URI 리소스를 가져야 하는지 결정하고, POST 방식에서는 서버가 어떤 URI 리소스를 가져야 하는지 결정합니다.
  • PUT은 구체적으로 작동하고 POST는 추상적으로 작동합니다.
  • 동일한 PUT 요청을 여러 번 보내면 결과는 그대로 유지되지만, 동일한 POST 요청을 여러 번 보내면 다른 결과를 받게 됩니다.
  • PUT 메서드는 멱등성이 있지만 POST 메서드는 멱등성이 아닙니다.
PUT 대 POST
PUT 대 POST

PUT 방법이란 무엇입니까?

PUT 메소드는 서버에서 사용 가능한 리소스를 업데이트하는 데 사용됩니다. 일반적으로 대상 URL에 존재하는 모든 것을 다른 것으로 바꿉니다. 이를 사용하여 새 리소스를 만들거나 기존 리소스를 덮어쓸 수 있습니다. PUT은 동봉된 엔터티를 제공된 요청 URI(Uniform Resource Identifier) ​​아래에 저장해야 한다고 요청합니다.

POST 방법이란 무엇입니까?

POST는 HTTP에서 지원되는 방법이며

웹 서버가 요청된 메시지 본문에 포함된 데이터를 수락하는 것을 보여줍니다. POST는 World Wide Web에서 사용자가 생성한 데이터를 웹 서버로 보내거나 파일을 업로드할 때 자주 사용됩니다.

REST API에서 PUT과 POST의 차이점

PUT과 POST 방식의 중요한 차이점은 다음과 같습니다.

PUT POST
이 방법은 멱등적입니다. 이 방법은 멱등성이 아닙니다.
PUT 메소드는 이미 리소스 수집의 일부인 단일 리소스를 수정해야 할 때 호출됩니다. POST 메서드는 리소스 컬렉션 아래에 하위 리소스를 추가해야 할 때 호출됩니다.
RFC-2616은 PUT 메서드가 제공된 요청 URI에 저장된 포함된 엔터티에 대한 요청을 보내는 것을 설명합니다. 이 메소드는 요청에 포함된 엔터티를 수락하도록 서버에 요청합니다.
PUT 메소드 구문은 PUT /questions/{question-id}입니다. POST 메서드 구문은 POST /questions입니다.
PUT 메소드 응답을 캐시할 수 없습니다. POST 메소드 응답을 캐시할 수 있습니다.
PUT /vi/juice/orders/1234는 "1234"로 식별되는 리소스를 업데이트하고 있음을 나타냅니다. POST /vi/juice/orders는 새 리소스를 생성하고 리소스를 설명하는 식별자를 반환함을 나타냅니다.
동일한 요청을 여러 번 보내면 결과는 동일하게 유지됩니다. 동일한 POST 요청을 두 번 이상 보내면 다른 결과를 받게 됩니다.
PUT은 구체적으로 작동합니다. POST는 추상적으로 작동합니다.
PUT에서는 UPDATE 쿼리를 사용합니다. POST에서는 생성 쿼리를 사용합니다.
PUT 방식에서는 클라이언트가 어떤 URI 리소스를 가져야 하는지 결정합니다. POST 방식에서는 서버가 어떤 URI 리소스를 가져야 하는지 결정합니다.

PUT의 예

다음은 PUT 메소드의 웹서버 예입니다.

HTTP PUT http://www.google.com/users/234

HTTP PUT http://www.google.com/users/234/accounts/567

의뢰

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 20

<p>New File</p>

응답

현재 표현을 갖고 있고 포함된 표현의 상태로 수정된 대상 리소스가 있는 경우 서버는 두 개의 응답을 보내야 합니다. 첫 번째 응답 코드는 200(OK)이고 두 번째 응답 코드는 204(No Content)입니다.

대상 리소스에 표현이 없으면 서버는 201 코드(생성됨) 응답을 보내 사용자에게 알려야 합니다.

 HTTP/1.1 201 Created
Content-Location: /new.html

POST의 예

다음은 POST 메서드의 예입니다.

HTTP POST http://www.google.com/users

HTTP POST http://www.google.com/users/234/accounts

기본 application/x-www-form-urlencoded 콘텐츠 유형을 사용하는 양식:

POST /test HTTP/1.1
Host: abc.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 40

field1=value1&field2=value2

PUT 요청으로 API 테스트

PUT 요청으로 API를 테스트하는 단계는 다음과 같습니다.

PUT 요청으로 API 테스트
PUT 요청으로 API 테스트

단계 1) PUT 요청으로 리소스를 업데이트합니다.

단계 2) 자원에 대해 GET 메소드를 사용하십시오. PUT 요청이 성공하면 새 데이터를 받게 됩니다. 요청에 제공된 데이터가 유효하지 않은 경우 이 메서드는 실패합니다. 따라서 아무것도 업데이트되지 않습니다.

POST 요청으로 API 테스트

POST 요청으로 API를 테스트하는 단계는 다음과 같습니다.

POST 요청으로 API 테스트

POST 요청으로 API 테스트

단계 1) POST 요청을 사용하여 리소스를 생성하고 200 상태 코드를 반환하는지 확인하세요.

단계 2) 해당 리소스에 대해 GET 요청을 수행하고 데이터를 올바른 형식으로 저장합니다.

단계 3) 잘못된 데이터로 인해 POST 요청이 실패하는지 확인하는 테스트를 추가해야 합니다.

PUT 방식의 장점

PUT 방법 사용의 장점/이점은 다음과 같습니다.

  • 제공된 URI 아래에 제공된 엔터티를 저장하는 데 도움이 됩니다.
  • 제공된 엔터티가 이미 존재하는 경우 업데이트를 수행할 수 있습니다. opera또는 해당 URI를 사용하여 생성할 수 있습니다.
  • 원하는 만큼 리소스를 생성할 수 있습니다.
  • PUT 방식으로 리소스를 생성하는 것은 매우 쉽습니다.
  • 사용자가 제출 버튼을 여러 번 클릭했는지 여부를 확인할 필요는 없습니다.
  • 요청에 포함된 엔터티를 식별할 수 있습니다.

POST 방식의 장점

POST 방법을 사용할 때의 장점/이점은 다음과 같습니다.

  • 이 방법은 리소스 URI를 결정하는 데 도움이 됩니다.
  • 위치 헤더를 사용하면 새 리소스 위치 헤더를 지정하는 것이 매우 쉽습니다.
  • URI로 식별되는 리소스의 새로운 하위 항목으로 엔터티를 수락하라는 요청을 보낼 수 있습니다.
  • 사용자가 생성한 데이터를 웹 서버로 보낼 수 있습니다.
  • 리소스를 보관할 URL을 모를 때 매우 유용합니다.
  • 리소스의 URL 생성을 제어하는 ​​서버가 필요할 때 POST를 사용하세요.
  • POST는 요청이 브라우저 기록에 남아 있지 않으므로 안전한 방법입니다.
  • 포스트를 이용하면 대용량의 데이터를 손쉽게 전송할 수 있습니다.
  • 데이터를 비공개로 유지할 수 있습니다.
  • 이 방법은 ASCII 데이터뿐만 아니라 바이너리 데이터도 보내는 데 사용할 수 있습니다.