3. HTTP 메시지
3-1 메시지 흐름
HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다.
1. 인바운드 , 2. 아웃바운드 , 3. 업스트림, 4.다운스트림은 메시지의 방향을 의미하는 용어이다
3-1-1 메시지는 원 서버 방향을 인바운드로 하여 송신된다
•
메시지가 클라이언트 → 서버 로 향하는 것은 인바운드 라고 한다
•
클라이언트로 돌아오는 걸 아웃바운드라고 한다,
3-1-2 다운스트림으로 흐르는 메시지
모든 메시지는 다운스트림으로 흐릅니다.
3-2 메시지 각 부분
3-2-1 메시지 문법
HTTP 메시지는 요청메시지, 응답 메시지로 분류된다
1. 요청 메시지 형식
<메서드><요청URL><버전>
<헤더>
<엔터티본문>
2.응답메시지 형식( 요청메시지에서의 시작줄에서만 문법이 다르다)
<버전><상태코드><사유구절>
<헤더>
<엔터티본문>
ㅁ 부가설명
사유구절 : OK부분을 의미한다.
헤더가 끝날때는 CRLF(빈줄)로 끝나야한다.
ㅁ 메서드
ㅁ 상태코드
•
클라이언트에게 무엇이 일어났는지 말해준다.
•
상태 코드는 각 응답 메시지의 시작줄의 담겨 반환된다.
•
숫자로 된 코드와 문자열로 되어 있어서 사람이 이해하기 쉬운 메시지 두 형태 모두로 반환된다.
◦
100-199: 정보
◦
200-299: 성공
◦
300-399: 리다이렉션
◦
400-499: 클라이언트 에러
◦
500-599: 서버 에러
3.안전한 메서드
안전한 메서드는 GET과 HEAD 메서드 처럼 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미한다.
안전한 메서드의 목적은 서버에 어떤 영향을 줄 수 있는 안전하지않은 메서드가 사용 될 때 사용자들에게 그 사실을 알려주는 HTTP 어플리케이션을 만들 수 있도록 하는것에 있다.
3.3.1 GET
•
서버에게 리소스를 달라고 요청하기 위한 메서드이다.
3.3.2 HEAD
•
HEAD메서는 GET처럼 행동하지만 서버는 응답으로 헤더만을 돌려받는다
•
엔터티본문은 반환되지 않는다.
◦
리소스를 가져오지 않고도 그에 대해 무엇인가(타입이라던가)를 알아낼 수 있다.
◦
응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
◦
헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
서버 개발자는 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다. 또한 HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어야 한다.
3.3.3 PUT
•
PUT 메서드는 서버에 문서를 쓰는 역할을 한다. PUT 메서드로 요청받은 서버는 요청 URL의 이름대로 새 문서를 만들거나, 이미 존재한다면 요청한 본문으로 교체한다.
3.3.4 POST
•
POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
•
PUT 메서드와 비슷하게 생각할 수 있지만 PUT 메서드는 서버에 있는 리소스에 데이터를 입력하기 위함이다.
•
POST와 PUT이 요청하는 데이터가 같을 수는 있지만 동작하는 의도가 다르다.
•
POST 메서드는 실제로 HTML의 form을 지원하기 위해 흔히 사용된다.
3.3.5 TRACE
•
TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
•
이 메서드는 주로 진단을 위해 사용된다.
•
TRACE 요청은 어떠한 엔터티 본문도 보낼 수 없다. 응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어있다.
3.3.6 OPTIONS
•
OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 아래의 그림과 같이 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.
3.3.7 DELETE
•
DELETE 메서드는 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다. 그러나 클라이언트는 삭제가 수행되는 것을 보장받지 못한다. 왜냐하면 HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시할 수 있기 때문이다.
3-4 상태코드
상태 코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.
3.4.1 100-199: 정보성 상태 코드
정보성 상태 코드는 HTTP/1.1에서 도입되었다. 이들은 비교적 새로운 것이며, 복잡함을 감수할 만한 가치가 있는지에 대해 논란이 되고 있다. 그래서 책에 있는 간단한 표만 적어본다.
3.4.2 200-299: 성공 상태 코드
3.4.3 300-399: 리다이렉션 상태 코드
•
리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
•
만약 리소스가 옮겨졌다면, 클라리언트에게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 Location 헤더를 보낼 수 있다.
•
3.4.4 400-499: 클라이언트 에러 상태 코드
3.4.5 500-599: 서버 에러 상태 코드
참조 : HTTP 완벽가이드
