김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 정리하는 포스트입니다.

HTTP 메서드

HTTP 메서드에 대해서 알아봅시다. HTTP 메서드 종류는 기본적으로 GET, POST, PUT, PATCH, DELETE가 있습니다. 각 메서드의 세부 내용을 살펴보기 전에 간단한 HTTP API를 만들어봅시다.

HTTP API를 만들어보자.

실무에 투입이 되었다고 가정해보겠습니다. ‘회원 정보 관리 API를 만들어라’는 요구사항이 주어졌을 때 다음과 같은 기능을 생각할 수 있을 것입니다.

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

자 그러면 여기서 URI를 만들려면 어떻게 만들어야 할까요? 개발을 접한지 얼마 되지 않았다면 다음과 같이 생각할 수 있습니다.

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

그렇다면 과연 이것은 좋은 URI 설계일까요? 한번쯤 고민해봐야 합니다.
URI를 잘 설계하기 위해 가장 중요한 것은 리소스의 식별입니다. 리소스가 무엇일까요?

리소스는 회원을 등록하고 수정하고 조회하는 것이 아닙니다. 예를 들어 LoL에서 챔피언이 CS를 먹어라고 명령을 내린다고 생각해봅시다. 여기서 ‘CS를 먹어!’에서 리소스는 CS입니다. 즉, 요구사항에서의 리소스는 회원이라는 개념 자체입니다.

그렇다면 리소스를 어떻게 식별하는게 좋을까요? 회원으로 하는 행동, 즉 등록, 수정, 조회하는 것을 배제하는 것입니다. 회원이라는 리소스만 식별해서 URI에 매핑하면 됩니다. 실제로 적용하게 되면 다음과 같이 될 수 있습니다.

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

리소스를 식별하고 URI의 계층 구조를 사용한 것은 좋은데 조회, 등록, 수정, 삭제가 동일한 URI를 가지고 있습니다. 어떻게 해야할까요? 여기서 메서드가 사용됩니다.

리소스와 행위를 분리

URI는 리소스만 식별해야 합니다. 그래서 리소스와 해당 리소스를 대상으로 하는 행위를 분리하면 다음과 같습니다.

• 리소스 : 회원
• 행위 : 조회, 등록, 삭제, 변경

보통 리소스는 명사가 되고, 행위는 동사가 됩니다. 그렇다면 이 행위(메서드)는 어떻게 구분할까요? 바로 HTTP 메서드가 그 역할을 해줍니다.

HTTP 메서드 - GET, POST

본격적으로 HTTP 메서드에 대해서 알아보겠습니다. 먼저 가장 많이 사용되는 GET과 POST를 살펴보겠습니다.

HTTP 메서드는 클라이언트가 서버에게 뭔가 요청을 할 때 기대하는 행동입니다. GET은 무언가를 달라는 것이고, POST는 데이터를 줄테니 처리해달라는 것입니다. 주요 메서드에 대해 간단히 살펴봅시다.

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

그 외에 다음과 같은 메서드들도 있습니다. 여기서 CONNECT와 TRACE는 거의 사용되지 않습니다.

• HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

GET

GET은 이름 그대로 리소스를 조회하는 메서드입니다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

위와 같은 형태를 가지고 ‘URL(PATH)에 있는 자원을 주세요’라고 요청을 보냅니다. GET 같은 경우 필요한 파라미터, 서버에 전달하고 싶은 데이터를 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달합니다.
참고로 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지는 않습니다.

GET의 동작 방식을 그림으로 표현하면 다음과 같습니다.

POST

POST는 클라이언트에서 서버로 요청을 보낼 때 데이터를 함께 보내서 요청 데이터를 처리해 달라고 전달하는 것입니다. 즉, 메시지 바디를 통해 서버로 요청 데이터를 전달하는 것이 핵심입니다.

서버는 요청 메시지(데이터)를 받아서 처리하는데, 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행합니다. 주로 전달된 데이터로 신규 리소스를 등록하거나 프로세스를 처리하는데 사용됩니다.

POST의 동작 방식은 아래와 같습니다.

그렇다면 POST가 요청 데이터를 어떻게 처리한다는 뜻일까요?

POST에 대한 스펙은 다음과 같이 정의되어 있습니다.
POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다.
한 번에 이해하기 어렵습니다. 그래서 예를 통해서 한 번 알아보겠습니다. POST는 다음과 같은 기능에 사용됩니다.

• HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
  • HTML FORM에 입력된 정보로 회원 가입, 주문 등에서 사용
• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
  • 게시판 글쓰기, 댓글 달기
• 서버가 아직 식별하지 않은 새 리소스 생성
  • 신규 주문 생성
• 기존 자원에 데이터 추가
  • 한 문서 끝에 내용 추가하기

이렇게 예시로 살펴봤는데 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 합니다. 즉 정해진 것이 없다는 것입니다.

정리해보면 다음과 같습니다.

1. 새 리소스 생성(등록)
   • 서버가 아직 식별하지 않은 새 리소스 생성
2. 요청 데이터 처리
   • 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
   • 예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
   • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
   • 예) POST /orders/{orderId}/start-delivery (컨트롤 URI)
3. 다른 메서드로 처리하기 애매한 경우
   • 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

POST는 메시지를 담아서 보내는 모든걸 할 수 있습니다. 하지만 앞서 GET에서 봤듯이 조회를 할 때는 GET을 사용하는게 유리합니다.
서버끼리는 GET이 오면 캐싱을 하기로 약속이 되어 있습니다. 하지만 POST로 오면 캐싱을 하기 어렵기 때문에 조회를 할 때는 GET을 사용하고, 그 외의 경우나 정말 어쩔 수 없을 경우에는 POST를 선택하면 됩니다.

HTTP 메서드 - PUT, PATCH, DELETE

PUT

PUT은 리소스를 대체합니다. 리소스가 있으면 대체되고 없으면 생성하는게 PUT입니다. 파일을 생각해봅시다. 어떠한 폴더에 파일을 넣었을 때 같은 파일이 있으면 덮어지고 없으면 생성이 됩니다.
PUT이 리소스를 대체할 때 중요한 포인트는 완전히 대체한다는 점입니다.

PUT의 형태를 잠시 살펴봅시다.

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
  "username" : "hello"
}

PUT의 경우 클라이언트가 리소스를 식별합니다. /members/100과 같이 클라이언트가 리소스의 위치를 알고 URI를 지정해서 전달합니다. 이 부분이 POST와 차이가 나는데 POST는 리소스의 위치를 특정하지 않습니다. 바로 이 점이 가장 큰 차이입니다.

정리하자면 PUT은 2가지 큰 특징을 가집니다. 하나는 리소스를 ‘완전히’ 대체한다는 점이고, POST와 달리 위치를 알고 클라이언트가 리소스를 식별한다는 점입니다.

리소스가 있을 때는 다음과 같습니다.

리소스가 없을 때는 다음과 같습니다.

마지막으로 중요한 완전히 대체한다는 것은 다음과 같습니다.

기존에 있던 username이 사라지고 전달된 age만이 존재하게 됩니다. 그렇다면 부분적인 수정을 하고 싶다면 어떻게 해야할까요?

PATCH

그럴 때 PATCH를 사용하면 됩니다. PATCH로 데이터를 전달하면 해당 부분만 변경하게 됩니다. 동작방식은 다음과 같습니다.

리소스를 부분변경하고 싶을 때 PATCH를 사용하는데 간혹 PATCH를 사용할 수 없는 서버가 있습니다. 그럴 때는 무적의 POST를 사용하면 됩니다.

DELETE

마지막으로 데이터를 지우고 싶을 때는 DELETE를 사용하면 됩니다.

HTTP 메서드의 속성

HTTP 메서드의 속성은 다음과 같습니다.

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시 가능(Cacheable Methods)

하나씩 살펴보겠습니다.

안전

안전하다는 것은 무슨 의미일까요? 호출을 해도 리소스를 변경하지 않는다는 의미입니다. 예를 들어 GET의 경우 단순히 조회만 하기 때문에 굉장히 안전합니다. 하지만 POST나 DELETE와 같은 것들은 안전하지 않습니다. 여러 번 호출했을 때 변경이 일어나지 않는 것을 안전하다고 합니다.

당연히 데이터를 변경하는 것들은 안전하지 않습니다.

만약 계속 호출을 해서 로그가 쌓이다가 장애가 발생할 경우에는 어떻게 할까요? 안전을 고려할 때 해당 리소스만 고려하기 때문에, 로그가 쌓이는 부분은 고려하지 않습니다.

멱등

멱등은 한 번 호출하든 백 번 호출하든 몇 번을 호출하든 결과가 같은 것을 말합니다. 멱등 메서드는 다음과 같습니다.

• GET : 몇 번 호출하든 같은 결과가 조회됩니다.
• PUT : 결과를 대체하기 때문에, 같은 요청을 여러 번해도 최종 결과는 같습니다.
• DELETE : 결과가 삭제됩니다. 같은 요청을 여러 번해도 삭제되기 때문에 같습니다.

POST는 멱등이 하지 않습니다. 두 번 결제하면 중복 결제가 됩니다.

멱등은 언제 사용될까요? 그리고 왜 필요할까요? 멱등은 자동 복구 메커니즘에 사용됩니다. 만일 클라이언트가 어떤 파일을 DELETE 요청했는데 응답이 느려써 또 시도했습니다. 몇 번을 시도해도 안전합니다. 이런 경우를 위해서 사용됩니다.

그렇다면 이런 경우에는 어떨까요? 사용자 A가 GET으로 리소스를 계속 요청하고 있는데, 사용자 B가 중간에 PUT으로 데이터를 변경해버리면 어떻게 될까요?
멱등은 외부 요인으로 중간에 리소스가 변경되는 것은 고려하지 않습니다. 오직 자기 자신이 요청한 것만 고려합니다. 위의 경우와 같은 것은 서버에서 중간에 체크를 해서 처리해줘야 합니다.

캐시 가능

우선 캐시를 간단하게 정의하면 엄청 큰 이미지를 매 번 가져오려면 오래 걸립니다. 그래서 웹브라우저가 이런 큰 이미지를 로컬 PC 내부에 저장하고 있는 것을 캐시라고 합니다.

캐시 가능은 응답 결과 리소스를 캐시해서 사용해도 되는가? 입니다. 메서드 중에서 GET, HEAD, POST, PATCH가 스펙 상 캐시 가능합니다. 하지만 실제론 GET, HEAD 정도만 캐시로 사용합니다.

캐시를 하려면 키가 맞아야 합니다. 똑같은 리소스라는 키가 맞아야하는데, POST나 PATCH의 경우 본문 내용까지 고려해야 하기 때문에 구현하기가 어렵습니다. 그래서 간단하게 검증 가능한 GET, HEAD만 캐시로 사용합니다.