1. 메시지 흐름
- 인바운드와 아웃바운드: 메시지가 원 서버로 향하는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것입니다.
- 다운 스트림과 업 스트림: 모든 메시지는 다운 스트림으로 흐릅니다. 메시지의 발송지는 수신자의 업 스트림입니다.
2. 메시지 문법
메시지는 시작줄, 헤더, 본문 이렇게 세 부분으로 이루어집니다. 시작줄은 이것이 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있습니다. 각 줄은 줄바꿈 문자열(CRLF)로 끝납니다.
요청 메시지
<메서드> <요청_URL> <버전>
<헤더>
<엔터티_본문>응답 메시지
<버전> <상태_코드> <사유_구절>
<헤더>
<엔터티_본문>3. 메서드
클라이언트 측에서 서버가 리소스에 대해 수행해 주길 바라는 동작입니다.
| 메서드 | 설명 | 메시지 본문 |
|---|---|---|
| GET | 서버에 어떤 문서를 가져옵니다. | |
| HEAD | 서버에서 어떤 문서에 대해 헤더만 가져옵니다. | |
| POST | 서버가 처리해야 할 데이터를 보냅니다. | 있음 |
| PUT | 서버에 요청 메시지의 본문을 저장합니다. | 있음 |
| TRACE | 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적합니다. | |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인합니다. | |
| DELETE | 서버에서 문서를 제거합니다. |
3.1. PUT과 POST
PUT과 POST의 차이는 Idempotent라는 개념의 도입이 필요합니다. Idempotent는 멱등의 법칙이라하며, 몇 번이고 같은 연산을 반복해도 같은 값이 나온다는 것입니다. POST는 클라이언트가 리소스의 위치를 지정하지 않았을 때 리소스를 생성하기 위해 사용하는 연산이며 Idempotent 하지 않습니다. 예를들어, Item을 생성하는 엔터티 본문을 /item으로 보내 연산을 수행하면 /item/1에 생기고, 그 다음번에 /item/2 등 매번 다른곳에 새로운 리소스가 생성될 수 있습니다. 반면 PUT은 리소스의 위치가 명확히 지정된 다음 요청을 보내며 Idempotent합니다. 예를들어, 동일한 Item을 생성하는 엔티티 본문을 item/3으로 보내면, 몇 번을 수행하더라도 같은 결과를 보장합니다.
3.2. TRACE Loopback
TRACE 요청은 목적지 서버에서 루프백(Loopback) 진단을 시작합니다. 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려줍니다. 클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌거나 수정되었는지, 만약 그렇다면 어떻게 변경되었는지 확인할 수 있습니다.
3.3. 확장 메서드
확장 메서드는 HTTP/1.1 명세에 정의되지 않은 메서드입니다. HTTP는 필요에 따라 확장해도 문제가 없도록 설계되어 있으므로, 새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않습니다.
4. 상태 코드
요청 중에 무엇이 일어났는지 설명하는 세 자리 숫자입니다.
4.1. 정보 (100 ~ 109)
정보성 상태 코드는 HTTP/1.1에서 도입되었습니다. 이들은 비교적 새로운 것이며, 복잡함을 감수할 만한 가치가 있는지에 대해 논란이 되고 있습니다.
4.2. 성공 (200 ~ 299)
서버는 대응하는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각 다른 종류의 요청에 대응합니다.
| 상태 코드 | 의미 |
|---|---|
| 200 | 요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있습니다. |
| 201 | 객체를 생성하라는 요청을 위한 것입니다. |
| 202 | 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았습니다. |
| 203 | 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔습니다. |
| 204 | 응답 메시지는 헤더와 상태줄을 포함하지만 엔터티 본문은 포함하지 않습니다. |
4.3. 리다이렉션 (300 ~ 399)
리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공합니다.
| 상태 코드 | 의미 |
|---|---|
| 300 | 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환합니다. |
| 301 | 요청한 URL이 옮겨졌을 때 사용합니다. |
| 302 | 요청한 URL이 임시로 옮겨졌을 때 사용합니다. |
| 303 | 리소스를 다른 URL에서 가져와야 한다고 말해주고자 할 때 쓰입니다. |
| 304 | 요청한 리소스가 최근에 수정된 일이 없다면, 이 코드는 리소스가 수정되지 않았음을 의미하게 됩니다. |
| 305 | 리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용합니다. |
| 307 | 요청한 URL이 임시로 옮겨졌을 때 사용합니다. |
위 표에서, 302, 303, 307 상태 코드 사이에서 중복되는 부분이 있음을 눈치챘을 것입니다. 이 상태 코드들이 어떻게 사용되는가에 대해서는 약간 미묘한 차이가 있는데, 주로 HTTP/1.0과 HTTP/1.1 애플리케이션이 이 상태 코드를 다루는 방식의 차이점에 기인합니다.
HTTP/1.0에서 서버는 POST 요청에 대한 응답 후 뒤이어 GET 요청이 오도록 302 상태 코드를 보낼 수 있습니다. 이는 일시적인 리다이렉션 상태 코드와 동일하여 혼란을 일으킵니다. 때문에 HTTP/1.1에서는 이러한 리다이렉션에 303 상태 코드를 사용하고, 일시적인 리다이렉트를 위해 302 상태 코드 대신 307 상태 코드를 사용하라고 합니다. 그리고 서버는 302 상태 코드를 HTTP/1.0 클라이언트에서 사용하기 위해 남겨둘 수 있을 것입니다. 결국 서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드르 선택하기 위해 클라이언트 HTTP 버전을 검사할 필요가 있습니다.
4.4. 클라이언트 에러 (400 ~ 499)
가끔 클라이언트 서버가 다룰 수 없는 무엇인가를 보냅니다.
| 상태 코드 | 의미 |
|---|---|
| 400 | 클라이언트가 잘못된 요청을 보냈다고 말해줍니다. |
| 401 | 리소스를 얻기 전에 클라이언트에게 스스로 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환합니다. |
| 403 | 요청이 서버에 의해 거부되었음을 알려주기 위해 사용합니다. |
| 404 | 서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용합니다. |
| 405 | 요청한 URL에 대해, 지원하지 않는 메서드로 요청받았을 때 사용합니다. |
| 408 | 클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 이 상태 코드로 응답하고 연결을 끊을 수 있습니다. |
4.5. 서버 에러 (500 ~ 599)
때때로 클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우가 있습니다.
| 상태 코드 | 의미 |
|---|---|
| 500 | 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용합니다. |
| 502 | 클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용합니다. |
| 503 | 현재는 서버가 요청을 처리해 줄 수 없지만 나중에는 가능함을 의미하고자 할 때 사용합니다. |
| 504 | 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 경우 사용합니다. |
| 505 | 서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용합니다. |
5. 헤더
헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용됩니다. 이름, 콜론, 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더가 있습니다.
- 일반 헤더: 요청과 응답 양쪽에 모두 나타날 수 있습니다.
- 요청 헤더: 요청에 대한 부가 정보를 제공합니다.
- 응답 헤더: 응답에 대한 부가 정보를 제공합니다.
- Entity 헤더: 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술합니다.
- 확장 헤더: 명세에 정의되지 않은 새로운 헤더입니다.
6. 출처
- [HTTP 완벽 가이드 - 웹은 어떻게 동작하는가] - 프로그래밍 인사이트
