HTTP 메서드

들어가며 - 리소스?

이전 HTTP 포스팅에서 언급한 HTTP 메시지의 시작줄(Start-line)의 첫 부분에 위치하는 HTTP 메서드에 대해 정리해 보겠습니다. HTTP 메서드에 알아보기에 앞서 API URI 설계할 때 중요한 리소스에 대해 다시 한번 정리해 보겠습니다. REST API에 대해 설명할 때도 리소스(자원)가 가장 중요하다고 언급했었습니다.

리소스는 HTTP 요청의 대상이며, 웹 서비스에서 제공하는 모든 것을 의미합니다. 예를 들어 '상품'과 관련된 '결제', '조회', '등록' 등의 기능이 있을 때, '상품'이 리소스(자원)가 되며 '결제', '조회', '등록'은 해당 리소스에 대한 행위입니다.

API URI를 설계할 때는 이러한 리소스를 식별하고 URI 계층 구조를 효과적으로 활용하는 것이 가장 중요합니다. 리소스에 대한 행위는 URI에 표현하지 않고 HTTP 메서드를 통해 정의합니다.

 

URL: 네트워크상에서 리소스의 위치 (예: https://example.com/users/100)
URI: URL + URN ( URN 은 거의 사용하지 않아 URI와 URL은 거의 비슷한 의미로 사용)

---

HTTP 메서드

HTTP 메서드는 클라이언트가 서버에게 요청하는 리소스에 대해 수행하고자 하는 행위를 알려주는 방식입니다.

주요 HTTP 메서드

1. GET

• 용도: 리소스 조회
• 특징:
  • 서버의 데이터를 변경하지 않는 읽기 전용 작업
  • 서버에 전달할 데이터는 쿼리 파라미터(query)를 통해 전달 → URL에 데이터가 노출되므로 보안에 주의
  • 메시지 바디를 통해 데이터 전달 가능 (권장 X)
• 사용 예시: 게시글 목록 조회, 상품 상세 정보 조회

GET /posts?userId=100 // 100번 회원의 게시글 목록 조회, 쿼리 파라미터 사용

 

2. POST

• 용도: 신규 리소스 생성, 요청 데이터 처리
• 특징:
  
  • 클라이언트에서 요청 데이터를 message body (메시지 본문)에 포함하여 서버에 전달
  • 서버에서 요청데이터 처리
  • 다른 메서드로 처리하기 어려운 경우에도 사용함
• 사용 예시: 회원가입, 게시글 작성

POST /posts          // 새 게시글 작성

 

3. PUT

• 용도: 리소스 대체(전체)
• 특징:
  • 리소스를 완전히 대체 → 기존 리소스를 요청한 내용으로 완전히 대체, 요청에 포함되지 않은 기존 필드는 삭제
  • 해당 리소스가 없으면 생성
  • message body (메시지 본문)를 통해 데이터 전송
• 사용 예시: 회원 정보 전체 수정

PUT /users/100       // 100번 회원 정보 전체 수정

 

4. PATCH

• 용도: 리소스 수정(일부)
• 특징:
  • 리소스의 일부만 수정
  • message body (메시지 본문)를 통해 데이터 전송
• 사용 예시: 사용자 프로필 이미지만 변경

PATCH /users/100     // 100번 회원의 일부 정보만 수정

 

5. DELETE

• 용도: 리소스 삭제
• 특징:
  • 지정된 리소스를 삭제
  • message body (메시지 본문) 를 통해 데이터 전송
• 사용 예시: 게시글 삭제

DELETE /posts/123    // 123번 게시글 삭제

 

---

HTTP 메서드 속성

1. 안전성(Safe)

• 리소스를 변경하지 않는 메서드
• GET, HEAD는 안전한 메서드

2. 멱등성(Idempotent)

• 여러 번 호출해도 결과가 동일 → 자동 복구 메커니즘
• GET, PUT, DELETE는 멱등성 보장

3. 캐시 가능성(Cacheable)

• 응답 결과 리소스를 캐시 해서 사용
• GET, HEAD, POST는 캐시 가능 -> 실제로는 GET, HEAD가 주로 캐시에 사용됨

---

데이터 전송

데이터 전송 방식은 GET 메서드에서 사용되는 쿼리 파라미터(query)와 POST, PUT, PATCH 메서드에서 사용되는 message body (메시지 본문)가 있습니다. 이러한 데이터 전송 방식을 통해 클라이언트에서 서버로 데이터를 전달하는 상황을 다음과 같이 크게 4가지로 나눌 수 있습니다.

1. 정적 데이터 조회 → GET 사용
2. 동적 데이터 조회 → GET + 쿼리파라미터 사용
3. HTML Form을 통한 데이터 전송 → GET, POST만 지원
4. HTTP API를 통한 데이터 전송 → HTML Form 외의 모든 HTTP 통신

HTML Form

HTML FORM은 웹 브라우저에서 사용자 입력을 서버로 전송하는 전통적인 방식입니다.

• GET, POST만 지원: 데이터를 변경 및 생성할 때 POST, 조회할 때 GET
  • 이런 제약으로 HTTP 메서드로 행위를 표현하기 어려움 
  • 이로 인해 리소스와 행위를 HTTP 메서드만으로 완벽하게 분리하기 어려운 상황이 발생 → 컨트롤 URI 방식 사용
  • 컨트롤 URI 방식: URI 경로에 행위를 명시 

# HTTP API 설계
DELETE /members/100  # 회원 삭제

# HTML Form 설계: DELETE를 사용할 수 없음
POST /members/100/delete  # 컨트롤 URI 사용

• 컨텐츠 타입 제한: application/x-www-form-urlencoded (기본값)

HTTP API

HTTP API는 서버 to 서버 통신, 앱 클라이언트, 웹 클라이언트(Ajax) 등에서 사용하는 현대적인 통신 방식입니다.

• 모든 메서드 사용 → 리소스와 행위를 분리하여 설계 가능
• 다양한 컨텐츠 타입
  • application/json (가장 많이 사용)
  • application/xml
  • custom media type

 

URI 위치 지정 방식

HTTP API를 URI 위치 지정 방식에 따라 컬렉션(Collection)과 스토어(Store)로 나눌 수 있습니다. HTTP API를 설계할 때 리소스의 URI를 "누가 결정하는가"에 따른 분류 방식입니다. 대부분의 경우 서버가 리소스 URI을 관리하여 안전하고 일관성 있는 컬렉션 방식을 사용합니다. 

 

POST 기반 (컬렉션)

• 클라이언트는 리소스의 최종 URI를 모름
• 서버가 새로운 리소스의 URI를 생성하고 지정
• 컬렉션 (Collection)
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 결정
  • 예시: /members (회원 관리)

POST /members
Body: { "name": "kim", "age": 30 }
→ 서버가 자동으로 /members/100 같은 URI 생성

 

PUT 기반 (스토어)

• 클라이언트가 리소스의 URI를 직접 지정
• 클라이언트가 리소스 위치를 알고 있어야 함
• 스토어 (Store)
  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • 예시: /files (파일 저장소)

PUT /files/hello.jpg
Body: {파일 데이터}
→ 클라이언트가 지정한 URI(hello.jpg)에 정확히 저장

---

[참고자료]

https://www.elancer.co.kr/blog/detail/74

강의: 모든 개발자를 위한 HTTP 웹 기본 지식