[Network] #19 HTTP 메서드

2025-01-01 4 분 소요

[혼자 공부하는 네트워크↗️], 컴퓨터 네트워킹: 하향식 접근 (제8판), 김영한 HTTP 웹 기본 지식을 바탕으로 정리한 글입니다.

1. HTTP API 만들기

1.1 API URL 설계

회원 정보 관리 API를 만들어보자.

회원 목록 조회 → /read-member-list
회원 조회 → /read-member-by-id
회원 등록 → /create-member
회원 수정 → /update-member
회원 삭제 → /delete-member

❌ 위 예시는 좋은 URL 설계가 아니다!

1.2 URL 설계에서 중요한 것

URL을 설계할 때 가장 중요한 것은 리소스 식별 이다.

리소스란 무엇일까?
- 회원을 등록, 수정, 조회하는 “행위”가 아니라, 회원 그 자체가 리소스다.
- e.g., “미네랄을 캐라”에서 리소스는 미네랄이다.
리소스를 어떻게 식별할까?
- 회원을 등록하고 수정하고 조회하는 행위를 배제하고 회원이라는 리소스만을 URI에 매핑하면 된다.

1.3 URL 설계의 좋은 예

리소스 식별과 URL 계층 구조 활용

회원 조회 → /members
회원 등록 → /members/{id}
회원 수정 → /members/{id}
회원 삭제 → /members/{id}

💡 계층 구조상 상위를 컬렉션으로 보고 복수 단어를 사용하는 게 좋다! (member → members)

❓ 그럼 위 URL을 어떻게 구분할까?

1.4 리소스와 행위 분리

핵심 원칙

리소스 식별
- 가장 중요한 것은 리소스를 식별하는 것
- URI는 리소스만 식별한다.
- e.g., 회원 리소스는 /members로 식별.
리소스와 행위 분리
- 행위(조회, 등록, 삭제, 수정)는 HTTP 메서드로 구분.

💡 리소스는 명사, 행위는 동사 (미네랄을 캐라)

HTTP 메서드 사용 예시

GET /members → 회원 목록 조회
GET /members/{id} → 회원 상세 조회
POST /members → 회원 등록
PUT /members/{id} → 회원 수정
DELETE /members/{id} → 회원 삭제

2. HTTP 메서드

요청 메서드	설명
GET	리소스 조회, 요청의 본문(body)에 데이터를 넣지 않음
HEAD	GET과 동일하지만, 응답 본문(body)을 포함하지 않고 헤더만을 반환
POST	- 요청 데이터 처리 - 주로 등록에 사용 - 요청의 본문에 새로 등록할 데이터를 넣어 보냄
DELETE	- 리소스 삭제 - 요청의 본문에 데이터를 넣지 않음 (URL로 리소스 지정)
PUT	- 리소스 전체 업데이트 (본문에 전체 데이터 포함) - 해당 리소스가 없으면 새로 생성
PATCH	리소스 부분 업데이트 (본문에 부분 데이터 포함)

2.1 GET - 조회

특정 리소스를 조회할 때 사용하는 메서드 (e.g., 웹 브라우저 URL 입력)

클라이언트가 서버에게 “이것을 가져다 주세요”라 요청을 보내는 것과 같다.
“이것” = 리소스(HTML, JSON, 이미지 파일이나 일반 텍스트 파일 등)

요청 메시지

http://www/example.com/example-page 에 대한 간략한 GET 요청 메시지

GET 요청 메시지에는 메시지 본문보다 query(쿼리 파라미터, 쿼리 스트링)이 사용되는 경우가 많다.
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

응답 메시지

GET 요청 메시지가 성공적으로 처리되었다면, 이에 대한 응답으로서 요청한 리소스를 전달받는다.

2.2 HEAD - 헤더 조회

HEAD 메서드를 사용하면, 서버는 요청에 대한 응답으로 응답 메시지의 헤더만 반환한다.

리소스의 메타데이터를 확인하고 싶을 때 (e.g., 콘텐츠 길이, 수정 시간, 콘텐츠 타입 등), 서버와의 트래픽을 줄이기 위해 응답 본문을 받지 않고, 헤더만으로 상태를 파악할 때 사용된다.

요청 메시지

http://www/example.com/example-page 에 대한 HEAD 요청을 보낸 예시

응답 메시지

2.2 POST - 등록

서버로 하여금 특정 작업을 처리 하도록 요청하는 메서드

메시지 바디를 통해 서버로 요청 데이터를 전달한다.
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용한다.
클라이언트의 입력 폼 작성 뒤 [게시하기] 버튼 클릭 가정

처리할 대상은 흔히 메시지 본문으로 명시된다.

GET 메서드 달리 POST 메서드는 메시지 본문을 명시한다.

POST 메서드는 많은 경우 “클라이언트가 서버에 새로운 리소스를 생성하고자 할 때” 사용한다.

새로운 리소스가 생성 되었다면, 서버는 응답 메시지의 Location 헤더를 통해 새로 생성된 리소스의 위치를 알려준다.
e.g., 게시하기 버튼 눌러 게시판에 글이 등록 되었을 때, 글이 등록된 url 위치를 location을 통해 응답 받을 수 있다.

POST 메서드를 사용하는 경우 정리

① 새 리소스 생성(등록)

서버가 아직 식별하지 않은 새로운 리소스를 생성할 때 사용한다.
e.g. POST /members → 요청 본문(body)에 회원 정보를 담아 전송하면 새로운 회원 리소스가 생성된다.

② 요청 데이터 처리 (프로세스 상태 변경)

단순 데이터 생성/변경을 넘어, 상태 변화 등 특정 프로세스를 처리해야 할 때 사용한다.
e.g.,
- 주문 상태 변경: POST /orders/{orderId}/start-delivery
- 결제 완료 처리: POST /orders/{orderId}/complete-payment
특징
- 반드시 새로운 리소스를 생성하지 않아도 된다.
- 특정 작업을 수행하기 위한 컨트롤 URI로 사용 가능하다.
- 리소스를 기준으로 최대한 URI를 설계하되, 어쩔 수 없는 상황에서는 컨트롤 URI를 사용할 수 있다.
- e.g., POST /orders/{orderId}/start-delivery (컨트롤 URI)

③ 다른 메서드로 처리하기 애매한 경우

애매하면 POST
e.g., JSON 데이터로 조회 결과 반환이 필요하나, GET 메서드로는 처리하기 어려운 경우

2.3 PUT - 전체 수정(덮어쓰기)

요청 리소스가 없다면 메시지 본문으로 리소스를 새롭게 생성

요청 리소스가 존재한다면 메시지 본문으로 리소스를 새롭게 대체(덮어쓰기)

POST와 PUT 차이점

POST: 서버가 URI 결정, 새 리소스 생성
PUT: 클라이언트가 리소스 위치를 알고 URI 지정, 전체 대체

2.4 PATCH - 부분 수정

메시지 본문에 맞게 리소스 일부를 수정하는 메서드

아래 그림은 앞선 예제의 요청 메서드를 PATCH 메서드로 바꿔 보낸 결과이다.

2.5 DELETE - 삭제

특정 리소스를 삭제하는 메서드

아래는 example.com/texts/a.txt라는 리소스를 삭제하도록 요청하는 메시지

3. HTTP 메서드의 속성

특성	설명	대표 메서드
안전 (Safe)	호출로 리소스를 변경하지 않음.	`GET`, `HEAD`
멱등 (Idempotent)	같은 요청을 여러 번 수행해도 결과가 동일.	`GET`, `PUT`, `DELETE`
캐시 가능 (Cacheable)	응답을 캐시로 저장하여 재사용 가능.	`GET`, `HEAD`

3.1 안전

안전(safe)이란, 호출해도 리소스를 변경하지 않는 것을 말한다.

요청을 여러 번 반복해도 리소스 상태가 유지된다.
예외: 호출로 인해 로그가 쌓여서 장애가 생길 수 있지만, 안전성은 해당 리소스의 상태에만 초점을 맞춘다. 그런 부분까지 고려하지 않는다.
대표 메서드: GET, HEAD

3.2 멱등성

멱등(Idempotent Methods)이란, 같은 요청을 한 번 또는 여러 번 수행해도 결과가 동일한 것을 말한다.

f(f(x)) = f(x)
한 번 호출하던 100번 호출하던 결과가 똑같다.

멱등 메서드

HTTP 메서드	설명
GET	여러 번 조회해도 같은 결과 반환.
PUT	요청된 내용으로 리소스를 대체하므로, 여러 번 호출해도 최종 결과는 동일하다.
DELETE	리소스를 삭제하므로, 여러 번 호출해도 삭제된 상태 유지된다.

⚠️ POST는 멱등이 아니다! 같은 요청을 반복하면 중복 동작(e.g., 결제)이 발생할 수 있다.

활용

자동 복구 메커니즘
서버 타임아웃 등으로 응답이 오지 않을 경우, 클라이언트가 안전하게 요청을 재시도할 수 있는 기준이 된다.
e.g., DELETE를 시도 했는데 서버가 응답이 없을 경우 멱등하기 때문에 DELETE 재시도 가능.

유의점

재요청 중간에 다른 곳에서 리소스를 변경해버리면?
- 사용자1: GET -> username:A, age:20
- 사용자2: PUT -> username:A, age:30
- 사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회

💡 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

3.3 캐시 가능

캐시 가능(Cacheable Methods)이란, 응답 결과를 캐시로 저장해 재사용할 수 있는가? 를 의미한다.

캐시 가능한 메서드
- 일반적으로 GET, HEAD
- 이론적으로 POST, PATCH도 가능하지만, 본문 내용을 캐시 키로 고려해야 하므로 구현이 복잡하다.
특징:
- 대부분의 경우, 캐시는 GET과 HEAD에만 적용한다.

💡 실무에서는 거의 GET만 캐시로 사용한다!

박시은