자원(Resource) : URI
행위(Verb) : HTTP Method
표현(Representations)
REST란 URI를 통해 자원을 식별하고, HTTP Method를 이용하여 자원에 대한 행위를 정의하며, 그 결과를 표현 형태로 응답받는 아키텍처 스타일이다.
멱등성이란 요청을 여러 번 수행해도 결과가 동일한 특성을 의미한다.
GET, PUT, DELETE는 멱등성을 가지며,
POST는 매 요청마다 새로운 자원을 생성하므로 멱등하지 않다.
이러한 특성에서 POST와 PUT의 주요 차이점이 발생한다.
POST 요청은 클라이언트가 리소스의 URI를 모르는 상태에서도 자원을 생성할 수 있다. 예를 들어, 클라이언트가 /payments로 요청을 보내면 서버는 내부 로직에 따라 /payments/1, /payments/2와 같이 URI를 생성한다. 이처럼 리소스의 URI 및 ID는 서버가 결정한다.
POST는 멱등하지 않다. 동일한 요청을 여러 번 보내면 매번 새로운 리소스가 생성된다. 예를 들어, 같은 본문의 요청을 3번 보내면 /payments/1, /payments/2, /payments/3과 같이 3개의 리소스가 만들어진다.
PUT 요청은 클라이언트가 리소스의 정확한 URI를 알고 있어야 한다. 예를 들어, /payments/1과 같이 명시된 URI로 요청을 보내야 자원이 생성 또는 갱신된다. 서버는 URI를 따로 생성하지 않으며, 주어진 URI에 대해 자원을 덮어쓴다.
PUT은 멱등한 메서드이다. 동일한 요청을 여러 번 보내더라도 결과는 항상 같다. 주로 리소스 전체를 갱신할 때 사용하며, 부분 갱신에는 적합하지 않다. 일부 필드만 수정하려 해도 전체 데이터를 함께 보내야 한다.
PATCH 요청은 PUT과 같이 리소스의 URI를 명확히 알아야 하지만, 전체 리소스를 대체하는 대신 일부만 수정할 수 있다. 필요한 필드만 요청 본문에 포함시키면 되고, 나머지 필드는 생략이 가능하다.
PATCH는 멱등하지 않고, 동시에 여러 요청이 수행될 경우 의도치 않은 결과가 발생할 수 있다. 리소스의 일부분만 변경하고 싶을 때 유용하게 사용되지만, 데이터의 정합성과 일관성이 중요한 경우에는 주의가 필요하다.
💡 REST는 URI로 자원을 식별하고, HTTP 메서드로 자원에 대한 행위를 정의함.
💡 멱등성은 요청을 여러 번 보내도 결과가 같은 성질이며, GET, PUT, DELETE는 멱등하지만 POST와 PATCH는 아님.
💡 POST는 리소스 URI를 알 필요 없이 서버가 ID를 생성하며, 호출할 때마다 리소스가 새로 생김.
💡 PUT은 클라이언트가 리소스의 URI를 알고 있어야 하며, 같은 요청을 반복해도 결과는 같음(멱등).
💡 PUT은 리소스 전체를 대체하며, 부분 수정에는 적합하지 않음 (→ 부분 수정은 보통 PATCH 사용).
https://docs.tosspayments.com/blog/rest-api-post-put-patch
https://velog.io/@cv_/GET-vs-POST-PUT-vs-PATCH-%EA%B0%81%EA%B0%81%EC%9D%98-%EC%B0%A8%EC%9D%B4