HTTP 메소드의 멱등성? 그게 뭔데?

Dion·2020년 7월 29일
25

TIL

목록 보기
1/21
post-thumbnail
post-custom-banner

HTTP 메소드의 멱등성

멱등성이 무엇인지 알고계신가요? 멱등성이란, 수학에서 사용하는 용어에서 유래한 것으로. 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 뜻합니다.

이 멱등성이 도대체 왜 HTTP Method와 연관이 되는걸까요?

HTTP 1.1 RFC 문서(RFC-2616)를 보시면 알 수 있습니다.

위의 글을 읽어보면, 오류와 같은 상황이 발생하는 경우는 예외상황이므로 멱등성을 판별할 때 제외됨을 알 수 있습니다.

근데, 사실 저 문서만 보고서는 저처럼 'REST API에서 뭐 어쩌라고?' 라는 생각이 드실 수 있습니다.

REST API

REST API에서 자주 사용하는 HTTP Method들이 있습니다. GET, POST, PUT, DELETE가 있죠.

이 중에서 POST를 제외하고는 모두 멱등성이 보장되어야 합니다.

그런데, 이 멱등성은 도대체 어떻게 이해해야 하는 것일까요?

멱등성은 무엇으로 판단할까?

멱등성은 '요청의 효과'를 보고 판단합니다.

서버의 상태는 멱등성이 유지되어야 하는경우 같은 행위를 여러 번 반복하더라도 같은 효과를 가져야 합니다.

멱등성이 성립하지 않으면, 같은 행위를 여러 번 반복하는 경우 요청마다 다른 효과가 발생된다고 생각하면 되겠죠?

즉, 이는 응답이 다를 수는 있지만, 요청이 의도한 효과를 발휘할 때 멱등성이 유지됨을 의미합니다.(여러 번 요청을 보내더라도 요청에 의한 서버의 상태는 항상 같음.)

그런데, 저도 잘못 알고 있던 개념이 있습니다. 바로 '안전한 메소드'입니다. 이 안전한 메소드에 대해서도 알아봅시다.

안전한 메소드

안전한 메소드는 GET, HEAD 와 같이 서버측의 상태 정보를 변경하지 않는 메소드를 가리킵니다.

이 안전한 메소드와 멱등성을 지키는 메소드는 서로 다르니 참고하시기 바랍니다. (저는 헷갈렸어요.)

자, 간단한 예를 봅시다.

우리가 REST API로 간단한 GET, POST, PUT, DELETE를 하는 API를 만들었다고 가정합시다.

먼저 우리는 어떤 Data를 생성합니다. POST 요청으로 생성하겠죠.

POST /data

POST요청을 반복하게 된다면 데이터들은 계속해서 추가가 될 것이고, 그 때 마다 서버의 응답은 다른 응답을 나타내며, 다른 효과를 지닐 것입니다. (같은 내용이더라도 서로 다른 데이터입니다.)

GET /data

GET요청으로 목록을 불러옵니다. 이 행위를 여러 번 수행한다고, 서버의 상태가 변하지도 않고(단순히 조회만 하므로), 같은 효과를 기대할 수 있습니다.(요청한 데이터 목록을 조회하는 효과) 따라서 멱등성과 안전한 메소드가 성립함을 알 수 있습니다.

PUT /data/3

PUT요청으로 3번째 Data를 수정한다고 합니다. 3번 데이터가 없는 경우 데이터가 생성 될 수 있습니다. 이미 존재한다면, 데이터는 수정이 됩니다. 그러면 PUT요청이 여러 번 실행되더라도 3번째 Data는 우리가 요청한 그 값으로 수정된 항상 같은 상태일 것 입니다.

DELETE /data/3

DELETE요청도 마찬가지입니다. 이미 존재하든, 존재하지 않든 그 데이터는 DELETE 요청을 보낸 시점에서 사라지게 되는 것입니다. 즉, 우리가 요청한 사항은 이루어졌음을 의미합니다.

요약

  • 안전한 메소드는 서버의 상태를 아예 변경시키지 않습니다.
  • 멱등한 메소드는 서버의 상태를 변경시킬 수도 있고, 시키지 않을 수도 있습니다. 다만, 우리가 요청한 사항은 에러가 나거나, 지연이 발생하지 않는 한 요청에 대한 서버의 상태는 항상 같습니다.

출처

profile
코드리뷰와 고양이를 좋아하는 개발자입니다. 좋은 글을 위한 비판은 언제든 환영합니다.
post-custom-banner

6개의 댓글

comment-user-thumbnail
2020년 12월 12일

네트워크 공부하던 중 멱등성에 대해서 찾고있었는데 감사합니다!

1개의 답글
comment-user-thumbnail
2021년 4월 13일

잘 읽었습니다 감사합니다~

1개의 답글
comment-user-thumbnail
2023년 5월 26일

정리 감사드립니다! 읽기 편해요!

1개의 답글