[TIL] REST API vs GraphQL, 멱등성

24 Mar 2025 in TIL on Til Last modified at: 2025-04-08

2025-03-24 TIL

📝 TIL (Today I Learned)
🔗 원본 이슈: #31
📅 작성일: 2025-03-24
🔄 최종 수정: 2025년 04월 08일

---

🍀 새롭게 배운 것

• REST API vs GraphQL
  • REST API는 알지만 GraphQL은 처음 들어서 비교해서 찾아보았다.
• 멱등성
  • API에 대해 더 찾아보다 멱등성이라는 단어 뜻을 잘 모르겠어서 이것 또한 공부해보았다.

🆚 REST API vs GraphQL

항목	REST API	GraphQL
형식	여러 개의 URL (엔드포인트)	단 하나의 URL
요청 방식	HTTP 메서드 (GET, POST 등)	GraphQL 쿼리 언어로 요청
데이터 반환	고정된 형식 (필드가 많을 수도 적을 수도 있음)	원하는 데이터만 선택 가능
과fetching/underfetching	있음 (필요한 것보다 많이/적게 받을 수 있음)	없음 (딱 원하는 데이터만 받음)
버전 관리	버전 필요 (ex. /v1, /v2)	필요 없음 (쿼리로 해결 가능)

---

🍔 비유로 이해하기

🍱 REST API는 세트 메뉴

• 예를 들어 /users/1에 요청하면:

  {
    "id": 1,
    "name": "Seongwoo",
    "email": "abc@abc.com",
    "posts": [...],
    "followers": [...]
  }
  

• 나는 name만 필요했는데, 이것저것 다 받아옴 → overfetching

---

🍔 GraphQL은 뷔페 스타일

• 같은 유저 정보를 GraphQL로 요청하면:

query {
  user(id: 1) {
    name
    email
  }
}

• 그럼 딱 이것만 받아온다:

{
  "data": {
    "user": {
      "name": "Seongwoo",
      "email": "abc@abc.com"
    }
  }
}

→ 필요한 것만 쏙쏙!

---

✅ 각 방식의 장단점

🔹 REST API

장점

• 간단하고 익숙함 (HTTP만 알면 됨)
• 웹 캐싱, 로깅 등 기존 기술과 잘 맞음

단점

• 불필요한 데이터 많이 받거나, 여러 번 요청해야 할 수 있음 (overfetching, underfetching)
• 버전 관리 필요할 수 있음

---

🔹 GraphQL

장점

• 원하는 데이터만 선택 가능 (쿼리 자유도 높음)
• 한 번 요청으로 여러 리소스도 OK
• 버전 관리 필요 없음

단점

• 쿼리 구조 학습 필요
• 캐싱이나 보안 관리가 REST보다 복잡함
• 단순한 API에는 오버스펙일 수 있음

---

📌 실제 선택 기준

상황	추천
단순하고 전통적인 API (ex. 블로그, 게시판)	REST API
클라이언트가 다양하고 데이터 구조가 복잡함 (ex. 모바일, 웹 앱 모두 지원)	GraphQL
프론트엔드 개발자와 백엔드 협업이 많고, 데이터 요청을 세밀하게 제어하고 싶다	GraphQL

---

✅ 멱등성(Idempotence)이란?

“요청을 몇 번 보내든 결과가 같으면 멱등하다”
(결과가 한 번 보냈을 때랑, 열 번 보냈을 때랑 똑같음)

---

🎨 비유로 이해하기

☕ 카페에서 “아이스 아메리카노 하나 주세요” 라고 한 번 말했을 때:

• 직원이 커피를 하나 만들어줌.

근데 내가 실수로 같은 말 3번 반복:

“아아 하나 주세요!”
“아아 하나 주세요!”
“아아 하나 주세요!”

🔥 멱등하지 않은 행동 → 커피 3잔 나옴 (요청마다 결과가 바뀜)

→ 커피를 여러 잔 주문하게 됨 = 멱등하지 않음

---

🧊 반면에 “제 테이블 물 좀 치워주세요!”라고 요청했을 때

직원이 한 번 치웠고, 내가 두 번 더 말해도
→ 테이블은 이미 깨끗하니까 더 이상 바뀌는 게 없어

✅ 멱등한 행동 → 몇 번 말해도 결과가 같다

---

✅ HTTP에서의 멱등성

메서드	멱등성	설명
GET	✅ 있음	몇 번 조회해도 데이터는 그대로
DELETE	✅ 있음	이미 지운 자원은 또 지워도 아무 일 없음
PUT	✅ 있음	같은 데이터로 덮어쓰기 = 결과 동일
PATCH	⚠️ 보통 있음	일부 수정이 동일하면 멱등, 하지만 상황에 따라 다름
POST	❌ 없음	새 데이터 생성 = 요청마다 다른 결과 생김 (예: id가 달라짐)

---

📦 예시 코드로 보기 (유저 정보 수정)

PUT (멱등함)

PUT /users/1
{
  "name": "Seongwoo",
  "email": "woo@email.com"
}

→ 몇 번 요청해도 name, email은 똑같이 덮어씀 = 멱등함

---

POST (멱등하지 않음)

POST /users
{
  "name": "Seongwoo",
  "email": "woo@email.com"
}

→ 요청할 때마다 새로운 유저 생성됨 (id=2, id=3…) = 결과 계속 달라짐

---

🎯 멱등성은 왜 중요할까?

1. 통신 오류/재전송 시 안전하게 설계

   • 같은 요청이 여러 번 가도 데이터 꼬임 없음

2. 캐싱/로깅/트랜잭션 처리에 유리

   • GET, PUT 등은 중간에 캐시해도 무방

3. 안정성 높은 API 설계 가능

---

✏️ 정리 한 줄 요약

멱등성 = 요청을 여러 번 보내도 결과가 똑같은 성질

---