HTTP

HTTP (HyperText Transfer Protocol)는, HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이다.
프로토콜은 컴퓨터 간의 통신을 원활하게 하기 위해 지키기로 한 규약이다. 

Client - Server 아키텍처에서 클라이언트가 HTTP messages 양식에 맞춰 요청을 보내면,
서버도 HTTP messages 양식에 맞춰 응답을 한다. HTTP는 특정 상태를 유지하지 않는
무상태성 (Stateless)의 특징을 갖고 있다. 

---

HTTP messages

HTTP messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이고 다음의 2 가지 유형이 있다.

• 요청 ( Request )
• 응답 ( Responses )

HTTP messages는 몇 줄의 텍스트로 구성된다. 다만 이 텍스트 들은 구성파일, API, 기타 인터페이스 등에서
자동으로 완성을 하며 직접 개발자가 작성할 필요가 거의 없다. 

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

요청과 응답은 다음의 유사한 구조를 갖는다.

start line	요청이나 응답의 상태를 나타낸다. 항상 첫 번째 줄에 위치. 응답에서는 status line이라고 부른다.
HTTP headers	요청을 지정하거나, 메세지에 포함된 본문을 설명하는 헤더 집합
empty line	헤더와 본문을 구분하는 빈 줄
body	요청과 관련된 데이터나 응답에 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용

 

---

요청 (Request)

[MESSAGE]  client >> server 

start line

1. 수행할 작업 (GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP 메서드를 나타낸다. 

2. 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 구문에 작성된다. 이 형식은 메서드마다 다르다. 

• Origin 형식
  ? 와 쿼리 문자열이 붙는 절대 경로이다. POST, GET, HEAD, OPTION 등의 메서드와 함께 사용한다.
  POST / HTTP 1.1 GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0
• Absolute 형식
  완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET 메서드와 함께 사용한다.
  GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
  
  
• Authority 형식
  Domain Name과 PORT번호로 이루어진 URL의 요소이다. HTTP 터널을 구축하는 경우,
  CONNECT와 함께 사용할 수 있다. 
  CONNECT developer.mozilla.org:80 HTTP/1.1
  
  
• Asterisk 형식
  OPTIONS와 함께 별표( * ) 하나로 서버 전체를 표현한다. 
  OPTIONS * HTTP/1.1
  

3. HTTP 버전에 따라 HTTP messages의 구조가 달라진다. 따라서 start line에 HTTP 버전을 함께 입력한다. 

 

---

 

Headers

요청의 Header는 다음의 기본 구조를 따른다. 값은 헤더에 따라 다르고, 여러 종류의 헤더가 존재한다. 

 

헤더 이름(대소문자 구분 없는 문자열),  ( : ), 값

General headers	메세지 전체에 적용되는 헤더  body를 통해 전송되는 데이터와 관련이 없다.
Request headers	fetch를 통해서 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함 하고있는 헤더
Representation headers	body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더  (구: Entity header)

** Request headers에서 'User-Agent', 'Accept-Type', 'Accept-Language'와 같은 헤더는 요청을 더욱 구체화한다. 
** Referer처럼 context를 제공하거나, 'If-None'과 같이 조건에 따라 제약을 추가할 수 있다. 

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

---

Body

Body는 요청 단계에서 HTTP message 구조의 가장 마지막에 위치하며 2 종류로 구분이 가능하다. 

! 모든 요청에 body가 필요한 것은 아니다. HTTP API 메서드: GET, HEAD, DELETE, OPTIONS처럼
서버에 리소스를 요청하는 경우에는 본문이 필요 없다. 

• Single-resource bodies (단일-리소스 본문) 
  2개의 헤더(Content-Type과 Content-Length)로 정의된 단일 파일로 구성
•  Multiple-resource bodies (다중-리소스 본문)
  여러 파트로 구성된 body에서는 각 파트마다 다른 정보를 갖고 있다. 통상 HTML form과 관련이 있다. 

---

---

HTTP 요청 방법

HTTP가 Request Message를 통해 클라이언트에서 서버로 데이터를 전달할 때는 
주로 아래의 3가지 방법을 사용한다.

• GET - 쿼리 파라미터
  • /url?username=danc&age=12
  • Message Body 없이 URL의 쿼리 파라미터에 데이터를 포함해서 전달
  • 검색, 필터, 페이징 등에 많이 사용된다.
• POST - HTML Form
  • content-type: application/x-www-form-urlencoded
  • Message Body에 파라미터 형식으로 전달 [username=danc&age=12]
  • 회원 가입, 주문, HTML Form 사용
• HTTP Message Body에 데이터를 직접 담아 요청
  • HTTP API(REST API)에서 주로 사용 [JSON, XML, TEXT]
  • 주로 JSON을 데이터 형식으로 사용
  • POST, PUT, PATCH

---

응답 (Response)

[MESSAGE]  server >> client 

Status Line

응답의 첫 줄은 Status line이라고 부르며 다음의 정보를 갖는다. 

•  현재 프로토콜의 버전 (HTTP/1.1)
•  상태 코드: 요청의 결과(200, 302, 403, 404 등)
•  상태 텍스트: 상태 코드에 대한 설명

---

Headers

요청 단계의 header와 동일한 구조를 갖으며, 마찬가지로 몇몇 헤더로 구분할 수 있다.

 

헤더 이름(대소문자 구분 없는 문자열),  ( : ), 값

General headers	메세지 전체에 적용되는 헤더  body를 통해 전송되는 데이터와 관련이 없다.
Response headers	위치 또는 서버 자체에 대한 정보(이름, 버전 등)과 같이 응답에 대한 부가적인 정보를 갖는 헤더
Representation headers	body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더  (구: Entity header)

** Response headers에서 'Vary', 'Accept-Ranges'와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다.

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

---

Body

응답의 body 또한 요청 단계에서 처럼 HTTP message 구조의 가장 마지막에 위치하며 2 종류로 구분이 가능하다.

! 모든 요청에 body가 필요한 것은 아니다. 201, 204와 같은 상태 코드를 갖는 응답에는 body가 필요하지 않다. 

• Single-resource bodies (단일-리소스 본문)
  • [길이가 알려진 경우] 2개의 헤더(Content-Type과 Content-Length)로 정의한다.
  • [길이를 모르는 경우] Transfer-Encoding이 chunked로 설정되어 있고, 파일은 chunk로 나뉘어 인코딩 된다. 
•  Multiple-resource bodies (다중-리소스 본문)
  여러 파트로 구성된 body에서는 각 파트마다 다른 정보를 갖고 있다. 통상 HTML form과 관련이 있다. 

 

---

무상태성 (Stateless)

Stateless는 상태를 가지지 않는다는 뜻이다. 

HTTP로 Client-Server 간의 통신 과정에서 HTTP가 Client나 Server의 상태를 확인하지 않는다. 

웹 쇼핑몰로 예를 들어보면, User는 로그인을 하거나, 상품의 상세 페이지로 이동해서 상품을 카트에 담거나,
로그아웃을 할 수 있다. 이렇게 클라이언트 쪽에서 발생한 모든 상태를 HTTP통신이 추적하지 않는다는 뜻이다.
HTTP는 통신 규약일 뿐이기 때문에 이런 상태를 저장하지 않는다.

하지만 로그인을 하지 않은 상태에서도 장바구니에 물건을 넣으면 나중에 돌아왔을 때에도 장바구니에
아이템이 남아있는 걸 볼 수 있는데, 이는 다른 방법(쿠키-세션, API 등)을 통해 필요에 따라
상태를 확인할 수 있게 처리한 것이다.

---

REST API

REST (Representational State Transfer) API는 웹에서 사용되는 데이터나 자원을 HTTP URI로써 표현하고
HTTP protocol을 통해 요청과 응답을 정의하는 방식이다. 

사용설명서 만들기 = API 개발 

https://appmaster.io/blog/how-create-api-no-code

---

좋은 REST API

REST API는 Dr Roy Fielding의 논문에서 웹(HTTP)의 장점을 최대한 활용할 수 있는 방법으로써
처음 소개되었다. 가장 핵심 포인트는 "리소스 식별"이다. 

이 이론을 실용적으로 적용하기 위해 Leonard Richardson의 Richardson Maturity Model
(RMM - 리차드슨의 성숙도 모델) 이 탄생하였는데 구조는 아래와 같다. (위로 올라갈수록 성숙도가 높다) 

https://devopedia.org/richardson-maturity-model

Dr.Fielding 은 위 모델의 모든 단계를 충족해야 좋은 REST API 모델이라 볼 수 있다고 주장했다.
하지만 실제로는 3단계까지 전부 충족하기 어렵기 때문에 2단계까지만 적용되어도
좋은 API 디자인이라 볼 수 있고, 이런 경우에 HTTP API라고 한다.

 

포인트: 

URI로 자원(리소스)을 표현해야 함

자원에 대한 행위는 HTTP Method로 정의

---

 

REST 단계별 설명

---

Level 0 - HTTP 사용

단순히 HTTP protocol을 사용하면 0단계를 충족한다. 현재 단계만 충족했다면
해당 API는 아직 REST API라고 할 수 없다. 좋은 REST API를 만들기 위해 기본적으로 거치는 단계라고 생각하자. 

---

Level 1 - 개별 리소스와의 통신 준수 

모든 데이터와 자원은 개별 리소스에 맞춰, Endpoint를 구분해서 사용해야 한다.
그리고 서버 측에서 요청으로 받은 자원에 대한 정보를 응답으로 전달해야 한다. 

Endpoint는 리소스에 포커스를 맞춘 '명사' 형태의 단어로 작성하는 게 좋다. 

응답으로 리소스를 전달할 때 사용한 리소스 정보 + 리소스 사용에 대한 성공/실패 여부도 반환해야 한다. 

---

Level 2 - HTTP 메서드 원칙 준수

CRUD에 맞게 적절한 HTTP 메서드를 사용해야 한다.  (POST, GET, PUT/PATCH / DELETE) 

메서드 사용 시의 조심할 규칙::

• GET 
  - 서버의 데이터를 변화시키지 않는 요청에 사용해야 한다. 
• POST / PUT
  - POST: 요청마다 새로운 리소스를 생성한다.
  - PUT  : 요청마다 같은 리소스를 반환한다 (멱등 - idempotent) 
  
  - 멱등성을 가지는 메서드 PUT과 그렇지 않은 POST를 구분해서 사용해야 한다. 
• PUT / PATCH
  - PUT     :  교체의 용도 
  - PATCH : 수정의 용도 

---

Level 3 - HATEOAS 원칙 준수 

HATEOAS (Hypertext As The Engine Of Application State)라고 불리는 하이퍼미디어 컨트롤을 적용한다. 

요청 방식은 2단계와 동일하다.

응답에서 차이가 있는데, 3단계 에서는 리소스의 URI를 포함한 링크 요소를 삽입해서 작성해 전달한다.

---

매우 유용한 링크 

 

HTTP 요청 메서드 - HTTP | MDN

 

HTTP 메시지 - HTTP | MDN

 

HTTP 상태 코드 - HTTP | MDN

 

 

MIME 타입 - HTTP | MDN

 

브라우저의 동작 원리: https://d2.naver.com/helloworld/59361