Http에 관한 이해

contents

HTTP 개요

문서

하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성된다.

프로토콜

규칙의 집합, 규약, 약속

애플리케이션 계층

계층(layer)는 OSI 7 layer 모형의 계층을 말한다. 애플리케이션 계층은 가장 높은 7계층이다. 식별자로 포트 번호를 사용한다. 웹 서버와 웹 브라우저는 모두 프로세스로 이들 끼리 통신할 때 식별자인 포트 번호가 필요하다.

클라이언트-서버 프로토콜

클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미한다. 클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부른다. 이 때 요청 및 응답의 대상을 서비스(리소스 보다 추상적인 개념) 혹은 리소스라고 부른다.

HTTP 메시지

  1. 기본적으로는 사람이 읽을 수 있는 형태를 지향한다.

  2. 기본적으로 요청과 응답 모두 동일 구조를 가진다. 구조는 아래와 같다. a. Start line : 첫 줄, 한 줄로 끝난다. 요청과 응답의 형태가 다르다. b. Headers : 헤더 세트, 헤더의 속성이 여러 개라고 생각하면 된다. c. 빈 줄 : 요청에 대한 모든 메타 정보가 전송되었음을 알린다. d. Body : 본문의 존재 유무 및 크기는 첫 줄과 헤더 세트에 명시된다.

    • 크기를 알기 어렵다. 페이로드가 얼마나 전달 됬을 때 의도한 대로 모두 다 받은지 확인하기 어렵다. 따라서 Headers의 Content-Length 항목 등을 활용한다.

    • 첫 줄, Headers와 다르게 꼭 사람이 읽을 수 있는 텍스트 형태일 필요는 없다. 바이너리 등 가능하다.

    • 하나가 아니라 여럿일 수도 있다. 파일 업로드 등을 위해 쓰이는 multipart/form-data가 대표적인 예다.

    HTTP 메시지의 시작 줄과 HTTP 헤더를 묶어서 '요청 헤드(head)' 라고 부르며, HTTP 메시지의 페이로드는 '본문(body)'이라고 한다.

HTTP Method

첫 줄에 들어간다. 주어진 리소스에 수행하길 원하는 행동을 나타낸다. 아래는 행동에 대한 설명이다.

  1. GET → Read

  2. HEAD → GET without body. 예를 들어 캐시 만료 여부 확인, 권한 확인, 404 Error 등 본문이 필요없을 때 활용된다.

  3. POST → Submit (멱등성 보장X) ⇒ Collection Pattern에서 Create작업에 사용한다.

  4. PUT → Update (+Create) Overwrite한다.

  5. PATCH → Update (partially) (멱등성 보장X) 나중에 도입되었다.

  6. DELETE → 말 그대로 삭제다.

  7. OPTIONS → 리소스에 대해서 어떤 메서드 지원하는지 확인할 수 있다.

HTTP Status Code

HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려준다.

  1. 1xx → 정보, 우리가 직접 쓰는 일은 드물다.

  2. 2xx → 성공. 200 OK, 201 Created, 204 No Content

  3. 3xx → 리다이렉션. 304 Not Modified을 특수한 형태로 자주 볼 수 있다. 새로 고침 했을 때 캐시를 그대로 사용하는 경우다.

  4. 4xx → 클라이언트 쪽 문제다. 404 Not Found

  5. 5xx → 서버 쪽 문제다. 500 Internal Server Error

Collection Pattern

Collection pattern은 RESTful API 디자인에서 자주 사용되는 용어 중 하나로 리소스에 대한 여러 작업을 수행하기 위한 패턴을 나타낸다. Collection pattern에서는 특히 리소스에 대한 생성(Create) 작업이 강조된다. 예를들어 블로그 게시물을 생성하는 RESTful API에서 Collection pattern을 사용할 수 있다. 리소스 표현:

  1. 리소스: 블로그 게시물 URI: /posts

  2. Create 작업: HTTP 메서드: POST 요청 바디: 새로운 블로그 게시물의 데이터 (제목, 내용 등)

  3. 처리 및 반환: 서버는 새로운 블로그 게시물을 생성하고 해당 게시물에 대한 식별자를 할당한다. 그리고 생성된 리소스에 대한 URI를 반환한다. (예: /posts/123)

사람이 읽을 수 있는 형태?

HTTP 메세지는 사람이 읽을 수 있는 형태라 가독성이 좋고 디버깅에 유리하다. 반면 사람이 읽을 수 없는 형태는 binary를 말한다.

리소스를 식별하기

웹에서 리소스를 식별하기 위해 URI(Uniform Resource Identifier)를 사용한다.

무상태 프로토콜

  1. HTTP는 각각의 요청이 독립적이다. 예를 들어 롯데리아에서 햄버거와 콜라를 주문할 때 각 주문의 주체와 같은 정보가 연속적으로 유지되지 않는다.

  2. 즉, 클라이언트는 항상 자신이 누구인지 알려줘야 한다. 아래는 대표적인 방법 3가지이다.

    a. 요청과 응답을 통해 계속 주고 받는 쿠키

    b. 데이터는 서버에서 관리하고 쿠키 등으로 key를 관리하는 세션

    c. 웹 브라우저의 기능 (localStorage 등)

쿠키

쿠키는 웹 서버가 생성하여 웹 브라우저로 전송하는 작은 정보 파일이다. 웹 브라우저는 수신한 쿠키를 미리 정해진 기간 동안 또는 웹 사이트에서의 사용자 세션 기간 동안 저장한다. 웹 브라우저는 향후 사용자가 웹 서버에 요청할 때 관련 쿠키를 첨부한다. 웹 서버는 쿠키를 통해 사용자를 식별하게 된다.

세션

세션은 사용자의 상태 정보를 서버 측에 저장하고 관리하는 기술이다. 세션을 통해 서버는 특정 사용자에 대한 정보를 일시적으로 저장하고, 해당 사용자의 연속적인 요청 간에 상태를 유지할 수 있다. 대표적으로 로그인 상태를 유지할 때 세션을 활용한다. 세션 식별자로 쿠키를 이용한다.

localstorage

localStorage는 브라우저에서 제공하는 클라이언트 측에서 데이터를 안전하게 저장하고 나중에 검색할 수 있는 간단한 키-값 쌍 형태의 로컬 저장소다.localStorage에 저장된 데이터는 브라우저를 닫아도 지속적으로 유지되며, 도메인별로 별도로 저장된다. Javascript로 간단하게 다룰 수 있다.

Previous1주차NextHttp Client

Last updated