<div id="readability-page-1" class="page"><cite>나를찾는아이</cite>
 2023. 7. 6. 14:54
 <div>
 멱등이라는 단어는 사실상 평생 쓸 일이 없는 단어입니다

그런데 HTTP method 에서 멱등성이라는 아주 생소한 단어가 등장하는데요

이것을 알면 더 좋은 http restful api를 설계하는데 큰 도움이 됩니다

추가로 면접관이 http method에 관한 질문을 할때 이 멱등성에 대한 내용까지 답한다면 플러스 알파를 얻게 되실 거예요


<a href="https://developer.mozilla.org/ko/docs/Glossary/Idempotent" target="_blank" rel="noopener">https://developer.mozilla.org/ko/docs/Glossary/Idempotent</a>
<figure id="og_1676260481897" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="website" data-og-title="멱등성 - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN" data-og-description="동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다. 다른 말로는, 멱등성 메" data-og-host="developer.mozilla.org" data-og-source-url="https://developer.mozilla.org/ko/docs/Glossary/Idempotent" data-og-url="https://developer.mozilla.org/ko/docs/Glossary/Idempotent" data-og-image="https://scrap.kakaocdn.net/dn/cLJ4kv/hyRAfZpYnM/K7vUaDIiNUphKeeAcS0Ix1/img.png?width=1920&amp;height=1080&amp;face=0_0_1920_1080"><a href="https://developer.mozilla.org/ko/docs/Glossary/Idempotent" target="_blank" rel="noopener" data-source-url="https://developer.mozilla.org/ko/docs/Glossary/Idempotent">

<div>
멱등성 - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다. 다른 말로는, 멱등성 메
developer.mozilla.org
</div>
</a><img src="https://scrap.kakaocdn.net/dn/cLJ4kv/hyRAfZpYnM/K7vUaDIiNUphKeeAcS0Ix1/img.png?width=1920&amp;height=1080&amp;face=0_0_1920_1080"></figure>
멱등성은 다행히 MDN 문서에 한글로 잘 번역이 되어있습니다


<blockquote data-ke-style="style1">동일한&nbsp;요청을&nbsp;한&nbsp;번&nbsp;보내는&nbsp;것과&nbsp;여러&nbsp;번&nbsp;연속으로&nbsp;보내는&nbsp;것이&nbsp;같은&nbsp;효과를&nbsp;지니고,&nbsp;서버의&nbsp;상태도&nbsp;동일하게&nbsp;남을&nbsp;때,&nbsp;해당&nbsp;HTTP&nbsp;메서드가&nbsp;멱등성을&nbsp;가졌다고&nbsp;말합니다</blockquote>


<blockquote data-ke-style="style1">멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안됩니다.</blockquote>



<blockquote data-ke-style="style1">올바르게&nbsp;구현한&nbsp;경우&nbsp;GET,&nbsp;HEAD,&nbsp;PUT,&nbsp;DELETE&nbsp;메서드는&nbsp;멱등성을&nbsp;가지며,&nbsp;POST&nbsp;메서드는&nbsp;그렇지&nbsp;않습니다.</blockquote>



가장 중요한 핵심문장입니다

동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는 것이 통계기록을 제외한 부수효과 없이 같은 효과를 지녀야 합니다


<pre id="code_1676260921516" data-ke-language="bash" data-ke-type="codeblock"><code>GET /users
GET /users/:id</code></pre>

이러한 API가 있다고 가정해봅시다

위의것은 유저 리스트를 제공하는 API이고 아래것은 단일 유저의 상세정보를 요청하는 API입니다

우리는 이러한 API를 요청할때 이 API를 여러번 호출한다고 이로 인해 user정보가 변경될것이라고는 전혀 예측하지 않을것 입니다

다른 메소드도 살펴볼까요

<pre id="code_1676260926250" data-ke-language="bash" data-ke-type="codeblock"><code>DELETE /users/:id</code></pre>

특정 유저정보를 삭제하는API입니다

이 API를 호출할때 우리는 당연히 해당 유저정보가 삭제될것이라고 생각하고

이 API를 여러번 호출한다고 삭제되었던 유저가 다시 생성되거나 할것이라고 기대하지 않습니다


<pre id="code_1676264476814" data-ke-language="bash" data-ke-type="codeblock"><code>PUT /users/:id

{
 firstname: 'firstname',
 lastname: 'lastname',
}</code></pre>

마찬가지로 PUT 메서드 역시 유저 정보를 수정할뿐 다른 부수효과를 일으킬것이라고 기대하지 않습니다


다만 PATCH 메서드는 멱등하지 않습니다

왜 그런지는 아래와 같은 예를 보면 알수 있습니다
<pre id="code_1676264470674" data-ke-language="bash" data-ke-type="codeblock"><code> PATCH /my/data HTTP/1.1
 Host: example.org
 Content-Length: 326
 Content-Type: application/json-patch+json
 If-Match: "abc123"

 [
 { "op": "test", "path": "/a/b/c", "value": "foo" },
 { "op": "remove", "path": "/a/b/c" },
 { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
 { "op": "replace", "path": "/a/b/c", "value": 42 },
 { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
 { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
 ]</code></pre>

PATCH 메서드를 통해 기존값에 특정 값을 더한 값을 갖도록하는 명령이 가능합니다

그러니깐 PUT 메서드로 값을 변경할때는 절대적으로 정해진 값으로 변경이 되지만

PATCH 메서드를 통해 값을 변경할때는 상대적인 값을 지정할수 있기에 호출시마다 서버의 상태가 달라지기에 멱등하지 않다고 얘기할수 있습니다


POST도 마찬가지로 서버에 특정 리소스를 계속해서 생성합니다

POST /users

위의 api를 100번 호출했다면 100명의 유저가 추가되는 셈이지요

그렇기 때문에 마찬가지로 멱등하지 않습니다

POST는 멱등하지 않은 이유로 매우 범용적으로 활용할수 있습니다



저는 심지어 모든 API method를 post로 구현한 어플리케이션도 종종보았습니다

우리가 적절한 method를 사용하여 api를 만드는 이유는 무엇일까요?

좀더 가독성 높고 이해하기 쉬운 API를 설계하고 사용하고자 하는 사람에게 API의 동작 의도를 설명하기에 매우 좋기 때문입니다
 
 
 </div></div>

나를 찾는 아이

Kyoung min, Kim

멱등이라는 단어는 사실상 평생 쓸 일이 없는 단어입니다
 
그런데 HTTP method 에서 멱등성이라는 아주 생소한 단어가 등장하는데요
 
이것을 알면 더 좋은 http restful api를 설계하는데 큰 도움이 됩니다
 
추가로 면접관이 http method에 관한 질문을 할때 이 멱등성에 대한 내용까지 답한다면 플러스 알파를 얻게 되실 거예요
 
 
https://developer.mozilla.org/ko/docs/Glossary/Idempotent
멱등성은 다행히 MDN 문서에 한글로 잘 번역이 되어있습니다
 
 
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다
 
 
멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안됩니다.
 
 
 
올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지며, POST 메서드는 그렇지 않습니다.
 
 
 
가장 중요한 핵심문장입니다
 
동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는 것이 통계기록을 제외한 부수효과 없이 같은 효과를 지녀야 합니다
 
 
GET /users
GET /users/:id
 
이러한 API가 있다고 가정해봅시다
 
위의것은 유저 리스트를 제공하는 API이고 아래것은 단일 유저의 상세정보를 요청하는 API입니다
 
우리는 이러한 API를 요청할때 이 API를 여러번 호출한다고 이로 인해 user정보가 변경될것이라고는 전혀 예측하지 않을것 입니다
 
다른 메소드도 살펴볼까요
 
DELETE /users/:id
 
특정 유저정보를 삭제하는API입니다
 
이 API를 호출할때 우리는 당연히 해당 유저정보가 삭제될것이라고 생각하고
 
이 API를 여러번 호출한다고 삭제되었던 유저가 다시 생성되거나 할것이라고 기대하지 않습니다
 
 
PUT /users/:id
{
  firstname: 'firstname',
  lastname: 'lastname',
}
 
마찬가지로 PUT 메서드 역시 유저 정보를 수정할뿐 다른 부수효과를 일으킬것이라고 기대하지 않습니다
 
 
다만 PATCH 메서드는 멱등하지 않습니다
 
왜 그런지는 아래와 같은 예를 보면 알수 있습니다
   PATCH /my/data HTTP/1.1
   Host: example.org
   Content-Length: 326
   Content-Type: application/json-patch+json
   If-Match: "abc123"
   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]
 
PATCH 메서드를 통해 기존값에 특정 값을 더한 값을 갖도록하는 명령이 가능합니다
 
그러니깐 PUT 메서드로 값을 변경할때는 절대적으로 정해진 값으로 변경이 되지만
 
PATCH 메서드를 통해 값을 변경할때는 상대적인 값을 지정할수 있기에 호출시마다 서버의 상태가 달라지기에 멱등하지 않다고 얘기할수 있습니다
 
 
POST도 마찬가지로 서버에 특정 리소스를 계속해서 생성합니다
 
POST /users
 
위의 api를 100번 호출했다면 100명의 유저가 추가되는 셈이지요
 
그렇기 때문에 마찬가지로 멱등하지 않습니다
 
POST는 멱등하지 않은 이유로 매우 범용적으로 활용할수 있습니다
 
 
 
저는 심지어 모든 API method를 post로 구현한 어플리케이션도 종종보았습니다
 
우리가 적절한 method를 사용하여 api를 만드는 이유는 무엇일까요?
 
좀더 가독성 높고 이해하기 쉬운 API를 설계하고 사용하고자 하는 사람에게 API의 동작 의도를 설명하기에 매우 좋기 때문입니다

당신의 REST API는 멱등한가요?

댓글