HTTP 메시지

• 메시지가 어떻게 흘러가는가
• HTTP 메시지의 세 부분 (시작줄, 헤더, 개체 본문)
• 요청과 응답 메시지의 차이
• 요청 메시지가 지원하는 여러 기능(메서드)들
• 응답 메시지가 반환하는 여러 상태 코드들
• 여러 HTTP 헤더들은 무슨 일을 하는가

3.1 메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다.
이 메시지는 클라이언트, 서버, 프락시 사이를 흐른다.

3.1.1 메시지는 원 서버 방향을 인바운드로 하여 송신된다

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 하용한다.

• 인바운드 : 서버 방향
• 아웃바운드 : 클라이언트 방향

3.1.2 다운스트림으로 흐르는 메시지

HTTP 메시지는 강물과 같이 흐른다. 요청, 응답에 관계없이 모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

3.2 메시지의 각 부분

• 시작줄, 헤더, 본문
• 줄바꿈 문자열은 CRLF라고 쓴다.

3.2.1 메시지 문법

• 요청과 응답 모두 기본적으로 구조가 같다.

요청

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

<엔티티 본문>

응답

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

<엔티티 본문>

엔티티 본문

헤더나 엔티티 본문이 없더라도 HTTP 헤더의 집합은 항상 빈 줄(그냥 CRLF)로 끝나야 함에 주의하라. 그러나 역사적으로 많은 클라이언트와 서버가 엔티티 본문이 없는 경우에 (실수로) 마지막 CRLF를 빠뜨린다. 이와 같이 널리 쓰이지만 규칙을 잘 지키지 않는 구현체와의 호환을 위해, 클라이언트와 서버는 마지막 CRLF 없이 끝나는 메시지도 받아들일 수 있어야 한다.

3.2.2 시작줄

모든 HTTP 메시지는 시작줄로 시작한다.

요청 시작줄 : 무엇을 해야 하는지 말해준다.
응답 시작줄 : 무슨 일이 일어났는지 말해준다.

HTTP/1.0 이전에는

• 요청줄에 HTTP 버전이 들어있을 필요가 없었다.
• 응답줄이 들어있을 필요가 없었다.

메서드

요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해준다.

메서드	설명	메시지 본문이 있는가?
GET	서버에서 어떤 문서를 가져온다.	없음
HEAD	서버에서 어떤 문서에 대해 헤더만 가져온다.	없음
POST	서버가 처리해야 할 데이터를 보낸다.	있음
PUT	서버에 요청 메시지의 본문을 저장한다.	있음
TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인한다.	없음
DELETE	서버에서 문서를 제거한다.	없음

HTTP는 쉽게 확장할 수 있돋록 설계되었기 때문에, 다른 서버는 그들만의 메서드를 추가로 구현했을 수도 있다. 이러한 추가 메서드는 HTTP 명세를 확장하는 것이기 때문에 확장 메서드라고 불린다.

상태 코드

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

사유 구절

상태 코드의 사람이 이해하기 쉬운 버전이다.
HTTP 명세는 사유 구절이 어때야 한다는 어떤 엄격한 규칙도 제공하지 않는다.

버전 번호

HTTP/x.y
어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킨다.
HTTP/2.22는 HTTP/2.3보다 크다. 왜냐하면 22는 3보다 큰 숫자이기 때문에

3.2.3 헤더

헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다.

이름/값 쌍의 목록

헤더를 여러 줄로 나누기

추가 줄 앞에는 최소 하나의 스페이스 혹은 탭 문자가 와야 한다.

Server: Test Server
       Version 1.0
-> Test Server Version 1.0

3.2.4 엔티티 본문

HTTP 메시지의 세 번째 부분은 선택적인 엔티티 본문이다. 여러 종류의 디지털 데이터를 실어 나를 수 있다.

3.2.5 버전 0.9 메시지

HTTP 버전 0.9는 HTTP 프로토콜의 초기 버전이다.
버전 정보도 없고, 상태 코드나 사유 구절도 없으며, 헤더도 포함되어 있지 않다.
단순함 때문에 다양한 상황에 대응할 수 없다.

3.3 메서드

서버는 모든 메서드를 구현하지 않는다!

3.3.1 안전한 메서드 (Safe Method)

HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미

GET, HEAD : 안전함

• 목적 : 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다.

3.3.2 GET

3.3.3 HEAD

GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다.

• 리소스를 가져오지 않고도 그에 대해 무엇인가(타입이라거나)를 알아낼 수 있다.
• 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다.

3.3.4 PUT

3.3.5 POST

서버에 입력 데이터를 전송하기 위해 설계되었다.

POST와 PUT의 차이

POST는 서버에 데이터를 보내기 위해 사용한다.
요청 URL에 서버의 리소스 주소를 명시하지 않고 도메인만 보낸다.
ex: POST /user

PUT은 서버에 있는 리소스에 데이터를 입력하기 위해 사용한다.
리소스의 정확한 식별값을 명시해야한다.
ex: PUT /user/userId

PUT과 PATCH의 차이

PUT	PATCH
리소스 전체 업데이트	부분 업데이트
멱등성 보장 O	보장 X

3.3.6 TRACE

주로 진단을 위해 사용된다.
요청은 어떠한 엔티티 본문도 보낼 수 없다. 응답의 엔티티 본문에는 서버가 받은 요청이 그대로 들어있다.

3.3.7 OPTIONS

웹 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어본다. 서버는 자신의 리소스에 대해 지원하는 메서드의 목록을 반환한다.

응답 헤더
Allow: GET, POST, PUT, OPTIONS

여러 리소스에 대해 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클라이언트 애플리케이션에게 제공한다.

궁금

-> API 명세서가 존재한다면 필요없는 메소드인건가? 실무에서도 구현을 해놓나?

멘토님 답변
-> 개발자분들이 구현 안해놔도 보통 웹 애플리케이션 구현체에 다 구현되어있습니다.
지금 스프링 부트로 웹 애플리케이션 띄워봐도 있을거에요.
다만, 보안 목적상 필요하다면 OPTIONS 메서드를 비활성화 하는 경우가 있긴합니다. API 명세서가 존재하는지와는 무관합니다~

cors, preflight 공부하기

3.3.8 DELETE

클라이언트는 삭제가 수행되는 것을 보장하지 못한다. 왜냐하면 HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.

3.3.9 확장 메서드

프락시는, 종단 간(end-to-end) 행위를 망가뜨리지 않을 수 있다면, 알려지지 않은 메서드가 담긴 메시지를 다운스트림 서버로 전달하려고 시도한다.
"엄격하게 보내고 관대하게 받아들여라"

3.4 상태 코드

다섯 가지로 나뉜다.

100-199: 정보성

HTTP/1.1에서 도입되었다. 복잡함을 감수할 만한 가치가 있는지에 대해 논란이 되고 있다.

상태 코드	사유 구절	의미
100	Continue	요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다. 이것을 보낸 후, 서버는 반드시 요청을 받아 응답해야 한다.

클라이언트와 100 Continue

서버와 100 Continue

프락시와 100 Continue

200-299: 성공

300-399: 리다이렉션

클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다. 브라우저가 사용자를 귀찮게 하지 않고 알아서 새 위치로 이동할 수 있게 해준다.

400-499: 클라이언트 에러

500-599: 서버 에러