TIL HTTP

백광호·2021년 2월 3일
TIL
0

TIL

목록 보기
44/55

새로 배운 것들

HTTP를 Web Architecture에 함께 적으려 했는데
내용이 너무 길어져 따로 뺐다.

HTTP

Hyper Text Transfer Protocol

하이퍼텍스트 문서(HTML)를 교환하기 위해 만들어진 Protocol(통신 규약)

클라이언트와 서버는 HTTP라는 프로토콜을 이용해 요청-응답을 주고 받는다.
이런 HTTP를 이용해 주고받는 메시지를 HTTP 메시지라고 한다.

주요 프로토콜의 종류

  • OSI 7 Layers(응용 계층)
프로토콜 이름설명
HTTP웹에서 HTML, JSON등의 정보를 주고 받는 프로토콜
HTTPSHTTP에서 보안이 강화된 프로토콜
FTP파일 전송 프로토콜
SMTP메일을 전송하기 위한 프로토콜
SSHCLI환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDPWindows계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WepSocket실시간 통신, Push등을 지원하는 프로토콜
  • OSI 4 Layers(전송 계층)
프로토콜 이름설명
TCPHTTP, FTP 통신 등의 근간이 되는 인터넷 프로토콜
UDP(양방향의 TCP와는 다르게) 단방향으로 작동하는훨씬 더 단순하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜

HTTP는 다음과같은 두가지 특징을 가지고 있다.

  • stateless(무상태성)

HTTP는 특정 상태를 담고 있지 않으며,
이전 요청이나 다음 요청을 기억하지 않는다
각각의 요청-응답은 독립적인 요청-응답이다.

그래서 만일 여러 요청과 응답의 진행과정이나
데이터가 필요할때는 쿠키나 세션 등등을 사용하게 된다.

  • connectionless(비연결성)

연결 상태를 유지시키지 않음
클라이언트와 서버가 서로 요청-응답 중에만 서로를 연결한다.

HTTP의 구조

HTTP는 request(요청)과 response(응답)으로 나눠져 있다.
이 중 request를 먼저 살펴보자

HTTP request 구조

HTTP request는 3부분으로 구성되어 있다.

  • startline
  • headers
  • body

startline

먼저 startline부터 살펴보자
startline은 여기서 또 3부분으로 나눠진다.

  • HTTP Method

해당 요청이 의도한 action을 정의하는 부분,
HTTP 메소드에는 GET, POST, PUT, DELETE등이 있다.
여기서 주로 GET과 POST를 많이 사용한다.

  • Request target

해당 요청이 전송한 목표 URL, 예를 들면 /login

  • HTTP Version

HTTP의 버전,
버전에는 1.0, 1.1, 2.0 등이 있다.

Headers

요청에 대한 추가 정보를 담고 있는 부분이다.
예를들면, 요청 메시지, body의 총 길이(Content-Length)등

또한 헤더의 값은 key-value로 구성되어있다.

  • 자주 사용되는 헤더

Host

요청이 전송되는 target의 host url

User-Agent

요청을 보내는 클라이언트에 대한 정보(웹 브라우저에 대한 정보)

Accept

해당 요청이 받을 수 있는 response(응답) 타입

Connection

해당 요청이 끝난 후에 클라이언트와 서버가
게속 네트워크 연결을 유지할 것인지에 대해 지시하는 부분

Connect-Type

해당 요청이 보내는 메시지 body타입
JSON을 보내면 application/json

Content-Length

메시지 body의 길이

Body

request(요청)의 실제 메시지 내용, Body가 없는 요청도 많다.
특히 GET request들은 대부분 body가 없는 경우가 많다.
여기서 보내는 데이터(body)를 Payload(페이로드)라고도 부른다.

POST /payment-sync HTTP/1.1

Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 83
Content-Type: application/json
Host: intropython.com
User-Agent: HTTPie/0.9.3

{
    "imp_uid": "imp_1234567890",
    "merchant_uid": "order_id_8237352",
    "status": "paid"
}

HTTP Response 구조

response(응답)도 request(요청)과 마찬가지로
3부분으로 구성되어 있다.

  • Status Line
  • Headers
  • Body

StatusLine

응답의 상태를 간략하게 나타내는 부분
여기서 또 3부분으로 구성된다.

  • HTTP 버전

  • HTTP Status Code(상태 코드)
    응답 상태를 나타내는 코드, 숫자로 구성되어 있다.
    ex) 200, 404, 502 등

  • Status Text
    응답 상태를 간략하게 설명하는 부분
    ex) 'Not Found' (HTTP/1.1 404 Not Found)

Headers

요청의 Headers와 동일하다.
다만 응답에서만 사용하는 header값이 있다.

  • User-Agent 대신 Server가 사용된다.
    (응답하는 서버에 대한 정보)

Body

요청의 Body와 거의 비슷하다.
요청과 마찬가지로 모든 응답이 body를 가지고 있진 않는다.
데이터를 전송할 필요가 없을 경우 body가 비어있게 된다.

HTTP/1.1 404 Not Found

Connection: close
Content-Length: 1573
Content-Type: text/html; charset=UTF-8
Date: Mon, 20 Aug 2018 07:59:05 GMT

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</ins>
  <p>The requested URL <code>/payment-sync</code> was not found on this server.  <ins>That’s all we know.</ins>

HTTP Status Code는 5개의 클래스로 분류되어있다.
상태 코드의 첫번째 숫자는 클래스를 정의하고
마지막 두자리는 해당 클래스의 오류 번호를 나타낸다.

첫자리에 대한 5가지 클래스는 다음과 같다.

  • 1xx (정보)

요청을 받았으며 프로세스를 계속한다

  • 2xx (성공)

요청을 성공적으로 받았으며 인식 후 수용했다.

  • 3xx(리다이렉션)

요청 완료를 위해 추가 작업 조치가 필요하다.

  • 4xx(클라이언트 오류)
    요청 문법이 잘못되었거나 요청을 처리할 수 없다.

  • 5xx(서버 오류)

서버가 명백히 유효한 요청에 대해 충족을 실패햇다.

Wikipedia HTTP 상태 코드
MDN HTTP 상태 코드
MDN MIME Type

API

Application Programming Interface의 약자로
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록
인터페이스를 제공하게 된다. 이것을 API라고 한다.

예를들면 카페의 메뉴판과 같이
손님이 엉뚱한 메뉴를 시키지 않도록 도와주는 것과 같이

서버가 리소스 전달을 위한 메뉴판, 즉 API를 구축해 놓아야
클라이언트가 이를 활용할 수 있다.

보통 인터넷에 있는 데이터를 요청할 때에는
HTTP 프로토콜을 사용하며 주소(URL, URI)를 통해 접근할 수 있다.

URL과 URI의 차이는 다음과 같다

  • URI
    Uniform Resource Identifier의 약자로
    Resource의 식별자이다.
    이 식별자는 리소스의 위치나 이름을 unique하게 나타낸다.
    현실에 비유하면 주민등록번호를 예로 들 수 있겠다.
    URI는 URL과 URN을 모두 포함하고있는 부모의 역활을 한다.
  • URL
    Uniform Resource Locator의 약자로
    Resource에 접근할 수 있는 위치를 나타낸다
    정리하자면 URL과 URI는 같지만 정확히 같지는 않은것이다.

URN은 URL과 비슷하나 주소가 아닌 이름으로 표시된다.

아래는 스타벅스 API 서버가 제공하는 URL 디자인 예제이다.

요청URL 디자인 예제
아메리카노 한 잔 주세요/coffee/americano
망고 프라푸치노 한 잔 주세요/frappuccino/mango
콜드브루 두 잔 주세요/coffee/coldbrew?quantity=2
아메리카노 두 잔 전부 헤이즐넛 시럽 넣어주세요/coffee/americano?quantity=2&syrup=hazelnet

여기서 syrup과 같은 옵션들을 파라미터라고 부른다

파라미터를 사용하기위해 물음표(?)와 & 기호를 사용했다.
이런식의 기호 사용을 Query String이라고 한다.

HTTP API 디자인에는 Best Practice가 존재한다.
위 예제와는 다르게 실제로 쓰일법한 API를 가져왔다.

사용자 관리 API라고 하며 URL 디자인은 단순하나 메소드개념이 등장한다.

요청URL 디자인사용하는 메소드
모든 사용자 조회/usersGET
새 사용자 추가/usersPOST
1번 사용자 정보 갱신/users/1PUT
1번 사용자 정보 삭제/users/1DELETE
1번 사용자 정보 조회/users/1GET

리소스와 관련된 행동을 지정할 수 있으며
CRUD(Create/Read/Update/Delete)와 비슷하다
좋은 레퍼런스 사이트 https://koreanjson.com

HTTP Method

HTTP 메소드는 여러가지가 있지만 CRUD에 맞는 메소드는 다음과 같다

요청적절한 메소드
조회(Read)GET
추가(Create)POST
갱신(Update)PUT 또는 PATCH
삭제(Delete)DELETE

위 다섯가지 메소드는 꼭 기억해두자
하나씩 살펴보면 다음과 같다

  • GET

어떠한 데이터를 서버로부터 받아올때 주로 사용한다.
데이터의 생성/수정/삭제 없이 받아오기만 한다.
가장 많이 사용되는 HTTP Method
주로 데이터를 받아올때 사용하기 때문에
request에 body를 안보내는 경우가 많다.

  • POST

데이터를 생성/수정/삭제할때 주로 사용하는 메소드
데이터를 생성 및 수정할 때 많이 사용하기 때문에
대부분의 경우 request에 body가 포함되서 보내진다.

  • PUT

POST와 비슷하게 데이터를 생성할 때 사용되는 메소드
POST와 겹치기 때문에 PUT을 사용하는 곳도 있고,
POST로 통일해서 사용하는곳도 있는데
최근엔 POST에 밀려서 잘 사용하지 않는다고 한다.

  • PATCH

리소스의 일정 부분을 수정하는데에 쓰인다.

  • DELETE

특정 리소스를 삭제하는 메소드

더욱 자세한 내용은 MDN HTTP 요청 메소드에서 확인할 수 있다.

profile
백광호
안녕하세요
이전 포스트

TIL Web Architecture

다음 포스트

TIL CORS

0개의 댓글

관련 채용 정보