Chapter 03 - HTTP 메시지

📌 읽으면서 밑줄친 내용 그대로 옮겨 적음. *이 붙은 문장은 생각.
  • HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다.
  • 요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐른다.

요청 메시지의 형식

<메서드> <요청 URL> <버전>
<헤더>

<엔티티 본문>

응답 메시지의 형식

<버전> <상태 코드> <사유 구절>
<헤더>

<엔티티 본문>
  • 사유 구절(reason-phrase)은 오로지 사람에게 읽히기 위한 목적으로만 존재하는 것이다.

많이 쓰이는 HTTP 메서드

메서드 설명 메시지 본문이 있는가?
GET 서버에서 어떤 문서를 가져온다. 없음
HEAD 서버에서 어떤 문서에 대해 헤더만 가져온다. 없음
POST 서버가 처리해야 할 데이터를 보낸다. 있음
PUT 서버에 요청 메시지의 본문을 저장한다. 있음
TRACE 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. 없음
OPTIONS 서버가 어떤 메서드를 수행할 수 있는지 확인한다. 없음
DELETE 서버에서 문서를 제거한다. 없음
  • HTTP는 쉽게 확장할 수 있도록 설계되었기 때문에, 다른 서버는 그들만의 메서드를 추가로 구현했을 수도 있다.

상태 코드의 종류

전체 범위 정의된 범위 분류
100-199 100-101 정보
200-299 200-206 성공
300-399 300-305 리다이렉션
400-499 400-415 클라이언트 에러
500-599 500-505 서버 에러
  • 응답의 프로토콜 버전이 HTTP/1.1이라는 것은 사실 응답을 보낸 애플리케이션이 HTTP/1.1까지 이해할 수 있음을 의미하는 것이다.
  • 어느 쪽이 큰 지 HTTP 버전을 비교할 때 각 숫자는 반드시 따로따로 비교해야 한다. 예를 들어, HTTP/2.22는 HTTP/2.3보다 크다. 왜냐하면 22는 3보다 큰 숫자이기 때문이다.
  • 긴 헤더 줄은 그들을 여러 줄로 쪼개서 더 읽기 좋게 만들 수 있는데, 추가 줄 앞에는 최소 하나의 스페이스 혹은 탭 문자가 와야 한다.
  • 모든 서버가 모든 메서드를 구현하지 않는다는 것에 주의하라.
  • GET이나 HEAD 메서드를 사용하는 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미한다.
  • 안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다(사실 그건 웹 개발자에게 달렸다).
  • HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다.
  • HEAD를 사용하면,
    • 리소스를 가져오지 않고도 그에 대해 무엇인가(타입이라거나)를 알아낼 수 있다.
    • 응답의 상태코드를 통해, 개체가 존재하는지 확인할 수 있다.
    • 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
  • 서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다.
  • PUT 메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다.
  • TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
  • HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용한다.
  • 확장 메서드(그리고 대부분의 HTTP 확장)를 다룰 때는 "엄격하게 보내고 관대하게 받아들여라"라는 오랜 규칙에 따르는 것이 가장 좋다.
  • 100 Continue 는 언제 쓸까?
  • Accept 관련 헤더들은 클라이언트는 그들이 원하는 것을 얻을 수 있으며, 서버는 클라이언트가 사용할 수도 없는 것을 전송하는 데 시간과 대역폭을 낭비하지 않을 수 있다.
  • 조건부 요청 헤더
    • 우리 서비스에도 이러한 로직의 API 가 있다. 헤더로 보내는 것과, 본문? 으로 보내는 것의 차이가 있을까?

알게된 점

  • HEAD, TRACE, OPTIONS 같은 메서드들. 주로 GET, POST 나 써봤고 PUT, DELETE 는 있다는 것은 알고 있으나 잘 안 쓰게 됨 (회사 API 에 있는 건 인지하고 있음)
  • 다양한 상태 코드들. 100번대와 300번대는 존재 자체를 몰랐다.
  • HTTP 버전 비교 방법
  • 안전한 메서드

관련해서 같이 이야기 나누고 싶은 점

  • HEAD 메서드는 GET 처럼 행동해야 하는데, 똑같은 연산을 해야 한다면 데이터 전송을 제외한 부분에서는 무슨 이점이 있는지…? 어떤 식으로 활용할 수 있을까요?
    • 어차피 리소스를 가져와야 하는 상황이면 단순히 알아내는 것이 무슨 의미가 있는지 잘 와닿지 않음. 오히려 불필요한 연산을 두 번 하게 되는 건 아닌지?
  • 읽으면서.. 기존 API 를 개선? 해보고 싶다는 생각한 게 있는지?
    • 요청할 때 date 를 넣는 경우가 종종 있는데(날짜 이후에 갱신된 내용이 있으면 해당 내용만 응답으로 돌아오는 API), header 에 넣는 방식으로 바꾼다면 뭐가 다를까? 라는 생각이 들었음

참고 자료