POST, PUT, PATCH의 차이 & 멱등성(Idempotent) 개념

 

 

node.js 강의를 들으면서 REST API 지식을 나름대로 활용하겠다고 app.put을 사용했는데

서버에는 app.get, 폼에는 POST method를 사용하는 것이다!  

 

 

음.....? 왜일까.

 

우선 MDN 문서를 보니 form에서는 get/post 만 사용 가능하다고 나와있고,

form에서 PUT/DELETE 사용시 method-override를 사용하면 된다고 한다.

 

GET은 조회, DELETE는 삭제 기능이라는 것을 직접 해보기도 했고 어느 정도 이해한 상태라서

PUT/PATCH는 정확히 언제 쓰이는 건지, POST와 PUT, PATCH의 차이는 정확히 뭔지 알고 싶어졌다.

 

비교를 위해 REST API 공식문서에서 POST, PUT, PATCH HTTP 메서드의 정의와 사용 예시를 가져왔다.

 

---

POST, PUT, PATCH의 차이

POST

POST 동사는 새 리소스를 생성하는 데 가장 자주 사용됩니다. 특히 하위 리소스를 만드는 데 사용됩니다. 즉, 다른 리소스(예: 부모 리소스)에 종속됩니다. 즉, 새 리소스를 만들 때 부모 리소스에 POST하면 서비스가 새 리소스를 부모 리소스와 연결하고 ID(새 리소스 URI)를 할당하는 등의 작업을 처리합니다.

생성에 성공하면 HTTP 상태 201을 반환하고, 새로 생성된 리소스에 대한 링크가 포함된 Location 헤더를 201 HTTP 상태로 반환합니다.

POST는 안전하지도 않고 무력하지도 않습니다. 따라서 비강제적 리소스 요청에 사용하는 것이 좋습니다. 두 개의 동일한 POST 요청을 하면 동일한 정보를 포함하는 두 개의 리소스가 생성될 가능성이 높습니다.

 

Examples:

• POST http://www.example.com/customers
• POST http://www.example.com/customers/12345/orders

PUT

PUT은 업데이트 기능에 가장 많이 사용되며, 원래 리소스의 새로 업데이트된 표현이 포함된 요청 본문과 함께 알려진 리소스 URI에 PUT합니다.

그러나 리소스 ID를 서버가 아닌 클라이언트가 선택한 경우 리소스를 생성하는 데에도 PUT을 사용할 수 있습니다. 즉, 존재하지 않는 리소스 ID의 값이 포함된 URI에 대한 PUT인 경우입니다. 다시 말하지만, 요청 본문에는 리소스 표현이 포함되어 있습니다. 많은 사람들이 이것이 복잡하고 혼란스럽다고 생각합니다. 따라서 이 생성 방법은 되도록이면 적게 사용해야 합니다.

또는 POST를 사용하여 새 리소스를 생성하고 본문 표현에 클라이언트 정의 ID를 리소스 ID가 포함되지 않은 URI에 제공하세요(아래 POST 참조).

업데이트가 성공하면 PUT에서 200(또는 본문에 콘텐츠를 반환하지 않는 경우 204)을 반환합니다. 생성에 PUT을 사용하는 경우, 생성에 성공하면 HTTP 상태 201을 반환합니다. 응답의 본문은 선택 사항이며, 본문이 있으면 대역폭이 더 많이 소모됩니다. 생성의 경우 클라이언트가 이미 리소스 ID를 설정했기 때문에 Location 헤더를 통해 링크를 반환할 필요가 없습니다.

PUT은 서버의 상태를 수정(또는 생성)한다는 점에서 안전한 작업은 아니지만, 무능한 작업입니다. 즉, PUT을 사용하여 리소스를 생성하거나 업데이트한 다음 동일한 호출을 다시 수행하면 리소스는 여전히 존재하며 첫 번째 호출과 동일한 상태를 유지합니다.

예를 들어 리소스에서 PUT을 호출하면 리소스 내의 카운터가 증가하면 호출은 더 이상 비활성화되지 않습니다. 가끔 이런 일이 발생하면 호출이 비활성 상태가 아니라는 것을 문서화하는 것으로 충분할 수 있습니다. 그러나 PUT 요청을 비활성 상태로 유지하는 것이 좋습니다. 비활성 요청에는 POST를 사용할 것을 강력히 권장합니다.

 

Examples:

• PUT http://www.example.com/customers/12345
• PUT http://www.example.com/customers/12345/orders/98765
• PUT http://www.example.com/buckets/secret_stuff

PATCH

PATCH는 수정 기능에 사용됩니다. PATCH 요청에는 리소스 전체가 아닌 리소스에 대한 변경 사항만 포함하면 됩니다.

이는 PUT과 비슷하지만 본문에는 현재 서버에 있는 리소스를 어떻게 수정하여 새 버전을 생성해야 하는지 설명하는 일련의 지침이 포함되어 있습니다. 즉, PATCH 본문은 리소스의 일부만 수정하는 것이 아니라 JSON Patch 또는 XML Patch와 같은 일종의 패치 언어로 작성해야 합니다.

PATCH는 안전하지도 않고 무력하지도 않습니다. 그러나 PATCH 요청은 무력화되도록 발행할 수 있으며, 이는 비슷한 시간대에 동일한 리소스에 대한 두 개의 PATCH 요청 간의 충돌로 인한 나쁜 결과를 방지하는 데 도움이 됩니다. 일부 패치 형식은 알려진 기준점에서 작동해야 하며 그렇지 않으면 리소스를 손상시킬 수 있기 때문에 여러 패치 요청의 충돌은 PUT 충돌보다 더 위험할 수 있습니다. 이러한 종류의 패치 애플리케이션을 사용하는 클라이언트는 클라이언트가 리소스에 마지막으로 액세스한 이후 리소스가 업데이트된 경우 요청이 실패하도록 조건부 요청을 사용해야 합니다. 예를 들어 클라이언트는 PATCH 요청의 If-Match 헤더에 강력한 ETag를 사용할 수 있습니다.

 

Examples:

• PATCH http://www.example.com/customers/12345
• PATCH http://www.example.com/customers/12345/orders/98765
• PATCH http://www.example.com/buckets/secret_stuff

 

 

---

멱등성(Idempotent)

HTTP 문서에 자주 나오기도 하고 생소한지라 용어도 같이 정리해보고자 한다.

 

사전적 의미

"수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질"

HTTP의 멱등성

참고 문서에 따르면 GET, PUT은 멱등성이 있으며 POST와 PATCH는 멱등성이 없다.

즉 POST, PATCH는 수정/업데이트에 많이 사용되기 때문에 결과가 달라지고 그래서 멱등성이 없는 것이다.

 

---

요약

 

PUT : 안전함 X 멱등성 O / 기존 리소스 전체를 교체, 일부만 수정시 나머지 값은 null/default 값으로 저장됨

POST : 안전함 X 멱등성 X / 새 리소스 생성, insert시 주로 사용 

PATCH : 안전함 X 멱등성 X / 리소스 일부만 수정

 

 

 

 

 

 

 

<참고 자료>

https://developer.mozilla.org/ko/docs/Glossary/Idempotent

https://yozm.wishket.com/magazine/detail/2106/