HTTP 메서드의 속성
주요 HTTP Method인 GET / POST / PUT / PATCH / DELETE 는 각 메서드의 동작 과정 뿐만 아니라, 메서드의 속성 또한 알 필요가 있다.
어떠한 HTTP 메서드로 서버에 요청했느냐에 따라 API 설계나 복구 메커니즘 캐시 최적화 등, 설계 로직이 달라질 수 있기 때문이다.
HTTP 메서드의 속성으로는 크게 3 가지인 안전(Safe), 멱등(Idempotent), 캐시 가능(Cacheable)이 있다.
안정성
HTTP 메소드의 안정성이란 보안 취약성을 말하는 것이 아니라 호출해도 리소스가 변경되지 않는 성질
| 안전 | |
|---|---|
| GET | O |
| POST | X |
| PUT | X |
| PATCH | X |
| DELETE | X |
GET 메서드는 단순히 데이터를 조회하는 기능을 수행하기 때문에 리소스를 변경 및 수정하지 않으니 안전한 HTTP 메소드이다.
반면에 POST PUT PATCH DELETE 와 같은 메서드들은 호출할 경우 데이터에 변경이 발생하거나, 서버에서 삭제되기 때문에 안전하지 않은 HTTP 메서드라고 볼 수 있다.
물론 트래픽이 몰려 수많은 GET 요청에 의해 서버가 터지게 되면 '안전성' 이라는 특성에 부합되지 않는다고 생각할 지도 모르겠지만, 여기서 말하는 안정성은, 리소스를 수정 / 삭제 하지 않으므로 데이터의 일관성 유지에 있어 안전하다는 의미이다.
즉, 메서드가 전체적인 시스템 장애로부터 안전하다는 의미를 가지지는 않는다.
멱등성
멱등(冪等)이라는 단어의 뜻은 수학이나 전산학에서 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
| 멱등 | |
|---|---|
| GET | O |
| POST | X |
| PUT | O |
| PATCH | X |
| DELETE | O |
위의 정의를 HTTP의 멱등성(Idempotent)에 대입해보자면, 멱등성이란 요청(Request)을 한 번을 호출하든 여러 번을 호출하든 그 결과가 같음을 의미한다. 즉, 동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 가지고, 서버의 상태도 동일하게 남을 때 해당 HTTP 메서드가 멱등성을 가진다고 말한다.
멱등의 개념을 안전(safe)과 혼동하기 쉬운데,
- HTTP 메소드의 안전이 한 번을 호출하든 여러 번을 호출하든 리소스에 수정이 발생하지 않는 속성이고,
- HTTP 메소드의 멱등은 리소스에 수정이 발생한다고 하더라도 메서드를 여러 번 실행한 결과가 한 번 실행한 결과와 같다면 만족하는 속성이라는 차이점이 있다.
또한 호출을 실행한 결과가 의미하는 것이 응답 상태 코드가 아닌 서버의 상태라는 점도 유의해야 한다. 예를들어 똑같은 요청을 했을 때 응답하는 상태코드가 다르더라도 서버의 상태가 같은 상태라면 멱등성이 있다고 판단하는 것이다
HTTP 스펙에 명시된 것에 의하면 GET, PUT, DELETE는 멱등성을 가지도록, POST와 PATCH는 멱등성을 가지지 않도록 구현해야 한다. 그 이유에 대해서 하나씩 살펴보자.
GET의 멱등(O)
GET은 데이터를 한 번을 조회하든 여러 번을 조회하든 같은 결과가 조회되므로 안전과 멱등을 동시에 만족하는 메서드이다.
다음은 GET 메서드로 호출되는 API에 대한 간략한 예시이다.
- GET /post/1 요청
- 서버에서 id값이 1인 게시글을 조회
- 해당 게시글 데이터를 응답
위의 경우 같은 요청을 여러번 보내더라도 서버의 상태는 항상 같게 된다.
이처럼 GET 메서드가 멱등성을 가져야 할 이유는 직관적으로 알 수 있다.
DELETE의 멱등 (O)
GET이 단순 조회라면, DELETE는 단순 삭제이다. 따라서 DELETE는 멱등성을 가진다.
DELETE를 처음 요청 하면, 서버에서 해당 리소스는 삭제가 된다. 이후 DELETE를 여러번 요청하더라도 해당 리소스는 삭제된 상태 그대로 일 것이니 서버의 상태는 변하지 않는다.
서버에서 삭제 동작이 되니 서버의 상태가 변경된 것이 아니냐라고 생각하겠지만, 다시한번 말하지만 멱등성은 한번 호출하든 두번 호출하든 결과 상태가 같다는 의미이지, 전혀 변경이 일어나지 않음을 의미하는 것은 아니다.
즉, 처음 요청하든 다시 여러번 요청을 하든 서버의 상태는 리소스가 삭제된 상태를 반환하고 추가적인 동작을 하지 않으니 멱등하다는 것이다.
POST의 멱등 (X)
반대로 POST 메서드는 멱등을 만족하지 않는다.
POST는 서버로 데이터를 전송하여 새로운 자원을 생성하는 역할을 한다. 따라서 요청을 여러번 보내는 경우 매번 새로운 자원이 생겨나는 것이며, 이는 서버의 상태가 변경되는 것을 의미한다.
PUT의 멱등 (O)
PUT 메서드는 대상 리소스를 덮어씌워 변경하거나, 대상 리소스가 없다면 새로 추가한다.
그래서 만일 대상 리소스가 없다면 PUT이 POST와 같은 동작을 하게 되는데, 반면 POST는 매번 새로운 자원을 만드는 반면, PUT은 해당 자원이 이미 있다면 데이터만 덮어쓴다.
따라서 요청을 한번하든 여러번하든 결국 서버의 상태는 같아지니, PUT은 멱등하다.
캐시 가능성
캐시 가능성은 응답 결과 리소스를 캐싱해서 효율적으로 사용할 수 있는가 에 대한 여부
| 캐시 가능 | |
|---|---|
| GET | O |
| POST | O (구현 x) |
| PUT | X |
| PATCH | O (구현 x) |
| DELETE | X |
캐시 가능성은 응답 결과 리소스를 캐싱해서 효율적으로 사용할 수 있는가 에 대한 여부이다.
캐시(Cache)가 꼭 운영체제나 서버에만 있는 것이 아니라, 브라우저 자체도 하나의 소프트웨어라 캐시 공간을 가지고 있는데, 클라이언트가 서버에 한 번 요청했던 데이터에 대해 매 요청마다 다시 전송할 필요가 없도록 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다.
즉, 캐싱이 가능한 HTTP 메소드는 빠르게 결과값을 받을 수 있다는 소리이다.
