Daily Dev Q&A: HTTP 메서드

Topic (오늘의 주제)

HTTP 메서드(HTTP Methods)의 종류와 의미, 그리고 RESTful API 설계

클라이언트가 서버에게 요청의 목적(행위)을 알리는 수단인 HTTP 메서드의 개념을 이해하고, 실무에서 이를 어떻게 표준(REST)에 맞게 활용하는지 학습합니다.

---

Why (왜 사용하는가? 왜 중요한가?)

• 실무: API를 설계할 때 메서드를 용도에 맞게 분리하지 않으면(예: 모든 요청을 POST로 처리), 다른 개발자가 코드를 보았을 때 해당 API가 데이터를 조회하는지, 수정하는지, 삭제하는지 엔드포인트(URL)만 보고는 파악할 수 없어 유지보수와 협업이 극도로 힘들어집니다.
• 구조적 의미: 자원(Resource)은 URL로 표현하고, 행위(Action)는 HTTP 메서드로 분리함으로써 시스템의 인터페이스를 직관적이고 일관성 있게(RESTful) 최적화합니다. 또한 HTTP의 캐싱 메커니즘을 효율적으로 활용할 수 있게 합니다.
• 면접 의도: 지원자가 웹 생태계의 기본 통신 규약을 잘 이해하고 있는지, **멱등성(Idempotence)**과 **안전성(Safety)**의 개념을 아는지, 그리고 PUT과 PATCH의 차이 같은 디테일한 설계 역량을 갖추고 있는지 확인하려 합니다.

---

Core Concept (핵심 개념 정리)

요소	내용
개념 정의	클라이언트가 웹 서버에게 요청하는 목적 및 종류를 알리는 표준 수단입니다. 주로 CRUD(Create, Read, Update, Delete) 연산과 매핑됩니다.
동작 방식	HTTP 요청 메시지의 첫 줄(Start Line)에 명시되어 서버로 전달됩니다. • GET: 데이터 조회 (Read) • POST: 새로운 데이터 생성 (Create) • PUT: 데이터 전체 교체/수정 (Update) • PATCH: 데이터 부분 수정 (Update) • DELETE: 데이터 삭제 (Delete)
장점/단점	장점: API 엔드포인트(URL)를 깔끔하게 유지할 수 있고, 캐싱(GET) 등 HTTP 프로토콜의 내장 기능을 100% 활용할 수 있습니다. 단점/한계: 구형 브라우저나 일부 엄격한 방화벽 환경에서는 GET과 POST만 지원하는 경우가 있어, 이를 우회하기 위한 설정(Hidden method 지원 등)이 필요할 때가 있습니다.
핵심 조건 (특징)	1. 안전성 (Safe): 호출해도 서버의 상태(데이터)를 변경하지 않는가? (GET 등) 2. 멱등성 (Idempotent): 동일한 요청을 1번 보내나 100번 보내나 서버의 결과 상태가 똑같은가? (GET, PUT, DELETE)
예시/비교	PUT vs PATCH: 회원 정보 중 '이름'만 바꿀 때, PUT을 쓰면 이름 외의 나머지 정보(나이, 이메일 등)를 같이 보내지 않을 경우 null이나 기본값으로 덮어씌워지는 대참사가 발생할 수 있습니다. 일부만 수정할 때는 PATCH를 써야 합니다.

---

Interview Answer Version (면접 답변식 요약)

"HTTP 메서드는 클라이언트가 서버에게 수행하고자 하는 행위를 알려주는 통신 규약입니다.

핵심 메서드로는 조회를 위한 GET, 생성을 위한 POST, 수정을 위한 PUT과 PATCH, 삭제를 위한 DELETE가 있습니다.

이를 통해 URL은 자원만 명시하고 행위는 메서드에 위임하는 RESTful한 설계를 할 수 있습니다. 특히 실무에서는 '멱등성'을 고려하는 것이 중요한데, 데이터를 전체 교체하는 PUT이나 삭제하는 DELETE는 여러 번 요청해도 결과가 같아야 하지만, POST는 호출할 때마다 새로운 데이터가 생성되므로 재시도 로직을 설계할 때 멱등성 여부를 반드시 주의해야 합니다."

---

Practical Tip (사용시 주의할 점 or 활용 예)

• 실무 활용 예:
  • 검색, 필터링, 페이징 처리는 데이터의 변경이 없으므로 쿼리 파라미터(Query String)와 함께 GET을 사용합니다.
  • 결제 처리, 회원 가입 등 새로운 리소스가 생성되는 작업은 POST를 사용하며, Body에 민감한 데이터를 담아 보냅니다.
• 설정 시 반드시 고려해야 할/주의할 점:
  • GET 요청에 Body 담기 금지: 이론적으로 GET 요청에도 HTTP Body를 담을 수는 있으나, 표준에 어긋납니다. 많은 웹 서버나 프록시 장비가 GET 요청의 Body를 무시하거나 버리기 때문에 예상치 못한 버그가 발생합니다. 검색 조건이 너무 길어 URL에 담기 어렵다면 예외적으로 POST를 활용하여 검색 API를 설계하기도 합니다.
• "이걸 모르고 사용하면 생기는 문제" (멱등성 부재로 인한 중복 결제):
  • 네트워크 지연으로 인해 클라이언트가 '결제하기(POST)' 버튼을 두 번 눌렀을 때, POST는 멱등성을 보장하지 않으므로 서버에 그대로 2건의 결제가 생성될 수 있습니다. 이를 막기 위해 클라이언트에서 고유한 Idempotency Key(멱등성 키)를 헤더에 담아 보내고, 서버가 이를 검증해 중복 POST 요청을 차단하는 방어 로직을 실무에서는 필수로 구현해야 합니다.

---

예상 꼬리질문 정리

1. GET과 POST의 차이점에 대해 캐싱(Caching)과 보안(Security) 관점을 포함하여 설명해 주시겠어요?
   • (의도: URL 파라미터 노출 여부, HTTP 캐시 컨트롤 적용 가능 여부 등 기본적인 차이를 명확히 아는지 확인)
2. PUT과 PATCH의 차이는 무엇이며, 각각 멱등성(Idempotence)을 만족하나요?
   • (의도: 전체 덮어쓰기와 부분 수정의 차이를 알고, 부분 수정(PATCH) 로직 작성 시 발생할 수 있는 멱등성 파괴 사례를 아는지 확인)
3. HTTP 1.1에 도입된 OPTIONS 메서드는 실무에서 언제 주로 발생하며, 어떤 역할을 하나요?
   • (의도: 프론트엔드와 백엔드 통신 시 자주 마주치는 CORS(Cross-Origin Resource Sharing)와 Preflight Request 개념 이해도 확인)