📚독서 스터디
벌써 3주차다!
3장을 읽어오고 문제를 만들어 가야 한다 :)
3주차도 읽은거를 정리해 보자.
HTTP가 인터넷의 배달원이라면 HTTP 메세지는 무언가를 담아 보내는 소포와 같다.
HTTP 메세지는 강물과 같이 흐른다. 요청인지 응답인지가 중요한게 아니다. 모든 메세지는 다운스트림으로 흐른다. 메세지의 발송자는 수신자의 업스트림이다.
-HTTP 완벽 가이드 p.49, 50-
📌메세지의 각 부분
HTTP 메시지는 단순한, 데이터의 구조화된 블록이다. 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다.
시작줄과 헤더는 그냥 줄 단위로 분리된 아스키 문자열이다. 각 줄은 캐리지 리턴과 개행 문자로 구성된 두 글자의 줄바꿈 문자열(CRLF)으로 끝난다. 본문은 텍스트나 이진 데이터를 포함할 수도 있고 비어있을 수도 있다.
시작줄
모든 HTTP 메시지는 시작줄로 시작한다. 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해준다.
요청줄
서버에게 리소스에 대해 무언가를 해달라고 부탁한다.
응답줄
응답 메시지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다. HTTP의 버전, 숫자로 된 상태 코드, 텍스트로 된 사유 구절이 들어있다.
메서드
요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해준다.
⚡GET
서버에서 어떤 문서를 가져온다. 메시지 본문 ❌
⚡HEAD
서버에서 어떤 문서에 대해 헤더만 가져온다. 메시지 본문 ❌
⚡POST
서버가 처리해야 할 데이터를 보낸다. 메시지 본문 ⭕
⚡PUT
서버에 요청 메시지의 본문을 저장한다. 메시지 본문 ⭕
⚡TRACE
메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. 메시지 본문 ❌
⚡OPTIONS
서버가 어떤 메서드를 수행할 수 있는지 확인한다. 메시지 본문 ❌
⚡DELETE
서버에서 문서를 제거한다. 메시지 본문 ❌
💥HTTP는 쉽게 확장할 수 있도록 설계 되었다. 다른 서버는 그들만의 메서드를 추가로 구현했을 수도 있다.
상태코드
메서드가 서버에게 무엇을 해야 하는지 말해주는 것처럼, 상태 코드는 클라이언트에게 무엇이 일어났는지 말해준다. 응답의 시작줄에 위치한다.
클라이언트의 요청이 항상 성공하지만은 않는다.
📘100 - 199 정보
✅200 - 299 성공
👉300 - 399 리다이렉션
💥400 - 499 클라이언트 에러
💥500 - 599 서버 에러
상태 코드 또한 우리가 인식할 수 없는 상태 코드를 받게 되면, 누군가가 현재 프로토콜의 확장으로 그것을 정의했을 가능성이 있다.
사유 구절
응답 시작줄의 마지막 구성요소다. HTTP/1.0 200 OK라는 줄에서, 사유 구절은 OK이다. 사유 구절은 상태 코드와 일대일로 대응된다.
버전 번호
HTTP/x.y 형식으로 요청과 응답 메시지 양쪽 모두에 기술된다. 이것은 HTTP 애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단이 된다.
헤더
여러 헤더 필드를 정의한다. 애플리케이션은 자유롭게 자신만의 헤더를 만들어낼 수 있다.
일반 헤더, 요청 헤더, 응답 헤더, entity 헤더, 확장 헤더
엔터티 본문
HTTP 메시지의 화물이라고 할 수 있다. HTTP가 수송하도록 설계된 것들이다.
📌메서드
모든 서버가 모든 메서드를 구현하지는 않는다. HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의한다. GET과 HEAD 메서드는 안전하다고 할 수 있는데, HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미하기 때문이다. 그렇지만 안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다. (사실 이건 웹 개발자의 몫이다.) 안전한 메서드의 목적은, 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다.
GET
서버에게 리소스를 달라고 요청한다.
HEAD
정확히 GET처럼 행동하지만 서버는 응답으로 헤더만을 돌려준다. 엔터티 본문은 결코 반환되지 않는다.
- 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
- 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
- 헤더를 확인해 리소스가 변경되었는지 검사할 수 있다.
PUT
서버에 문서를 쓴다. 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다.
POST
서버에 입력 데이터를 전송하기 위해 설계되었다. 채워진 폼에 담긴 데이터는 서버로 전송되며, 서버는 이를 모아서 필요로 하는곳에 보낸다.
TRACE
주로 진단을 위해 사용된다. 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사할 수 있다. 프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인해보고자 할 때도 좋은 도구다.
OPTIONS
웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.
DELETE
서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다. 그러나 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.
...
이 뒤에도 상태 코드와 헤더와 관련된 아주 자세한 내용이 책에 수립 되어 있다. 그렇지만 그 양이 상당해서 글로 요약하기에는 무리가 있기에... 키워드만!
🔥100-199: 정보성 상태 코드
클라이언트와 100 Continue,서버와 100 Continue, 프락시와 100 Continue
🔥200-299: 성공 상태 코드
200 : OK, 201 : Created, 202 : Accepted, 203 : Non-Authoritative Information 등등
🔥300-399: 리다이렉션 상태 코드
300 : Multiple Choices, 301 : Moved Permanently, 302 : Found 등등
🔥400-499: 클라이언트 에러 상태 코드
400 : Bad Request,401 : Unauthorized,402 : Payment Required,403 : Forbidden,404 : Not Found 등등
🔥500-599: 서버 에러 상태 코드
500 : Internal Server Error,501 : Not Implemented,502 : Bad Gateway 등등
