[Network] HTTP의 모든 것 (HTTP특징, URI 설계, 상태코드, 리다이렉션, 헤더)

들어가기전에

* URI, URL 의 차이를 모른다면?

[Network] URL? URI? URN?

* 프로토콜이 뭐지?

[Network] 통신 프로토콜의 발전에 대한 간략 정리글 (IP, TCP/UDP, HTTP)

 

 

HTTP (HyperText Transfer Protocol)

본래는 HyperText, 즉 html 전송을 위한 프로토콜이었으나,
요즘은 HTML, TEXT, JSON, 이미지, 음성, 영상, 파일등 모든 형태의 데이터
(바이트로 표현할 수 있는 모든 데이터)를 주고받는데 사용하고 있다.

서버간의 데이터 또한 HTTP로 대부분 주고 받는다.
(게임서버 같은 특수한 케이스는 TCP)

 

HTTP 의 역사

[Network] HTTP 프로토콜의 발전 (HTTP 1.1 vs HTTP2) 그리고 구글(HTTP3, QUIC)

 

 

클라이언트 - 서버 구조

Request - Response 구조를 가지고 있다.
서버와 클라이언트는 각각 독립적으로 고도화 할 수 있다.

 

Stateless & Stateful

[Stateless]
클라이언트측이 해당시점 요청한 정보만 응답한다.
기본적으로 서버가 클라이언트의 상태를 보존하지 않게 설계한다.
(즉 클라이언트는 자신이 필요한 정보를 상세하게 요청한다.)

이로 인해 scale-out 이 자유롭다.
하지만, 데이터 전송량이 Stateful 에 비해 많다.

[Statueful]
인증과 같은 작업을 위해 사용한다.
서버에 부담을 줄이기 위해, 또는 scale-out 이 자유롭기 위해 최소한으로만 사용한다.

 

비연결성 (connectionless)

TCP/IP 같은 경우는 통신이 끝나기 전까지 연결을 유지한다.

클라이언트가 언제 요청을 보낼지 모르기에 놀고 있어도 연결을 유지한다.
연결을 유지하는 클라이언트가 늘어나면 소켓(파일디스크립터, fd)이 고갈될 수 있다.

초기 HTTP 는 단일 요청에 대해 단일 응답을 하므로 연결을 유지하지 않게 설계되었다.

하지만 HTTP 가 지속적으로 발전함에 따라 지속 연결(Persistent Connections)을 채택하여 
TCP/IP 의 3-way handshake 오버헤드를 감소시켰다.

해당 사항은 글 상단의 HTTP의 역사를 참고하시길 바란다.

 

 

HTTP 메세지 구조

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

매우 단순한 구조이다.

크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술이라는 것을
개발자라면 머리에 넣어두자.

HTTP는 헤더에 부가정보를 추가하면서
서버-클라이언트간 필요한 메타데이터들을 정의하여 확장가능하고

HTTP의 시작라인 또한
HTTP 버전이 바뀌어도 기본틀은 바뀌지 않게 확장가능하고

HTTP의 바디 또한
처음에는 html 을 위한 영역이었으나
기본적으로 바이트로 표현하기에 모든데이터가 들어갈 수 있게 된 것이다.

 

API URI 설계

URI(U.. Resource .. I)는 리소스를 판별하기 위한 목적이다.

그래서 URI 에는 리소스정보만 담는 것이 좋다.

행위(동사)는 HTTP 메서드로 분리하여 설계한다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

자세한 내용은 아래 블로그 글을 참조하자.

RESTful API 설계 가이드

 

 

HTTP 메서드

RESTful 하게 API URI 를 설계하기 위해 아래와 같이 약속한 것이다.

HTTP 메서드는 HTTP 메세지의 start-line의 문자열일뿐이기에,
마음만 먹으면 다른기능을 수행하게 할 수도 있지만 권장하지 않는다.
(혼자사는 세상이 아니잖아... 🥺🥺🥺) 

어디서 주워들은 이야기인데, GET/POST 만 지원하는 구버전이 있다고 들었다.
일단 HTML FORM 태그는 GET/POST 만 지원하는 건 확실하다.
그런 경우에는 CQRS 느낌으로 조회와 명령을 GET과 POST에 매핑시키면 되지 않을까?
(해당부분은 추후 확실해지면 다시 수정하겠습니다) 

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

 

HTTP 메서드 - POST

조회는 왠만하면 다 GET 으로 해야, 서버에서 캐싱처리등을 할때 편함

되도록 리소스 생성 / 프로세스 상태 변경에만 POST를 사용할 것 

POST 요청에 대한 응답으로 리소스의 위치를 반환하게 하기도 한다.

클라이언트가 등록될 리소스 URI 를 모를때 사용한다.

 

HTTP 메서드 - PUT, PATCH

[PUT]
리소스를 완전히 OverWrite(덮어쓰기) 한다.

[PATCH]
리소스를 부분변경한다.

* PUT과 PATCH 모두 클라이언트가 리소스 위치를 알고 URI를 지정

여태 PUT으로도 부분변경 가능하도록 API를 설계했었는데
주의해야겠다. 😢

참고로 members 의 필드가 username, age 말고도 훨씬 많은데
PUT으로 위의 그림과 같이 요청을 보내게 될 경우
덮어쓰기(OverWrite)이기 때문에 모든필드가 삭제되고
username과 age만 남도록 설계해야하는 것이 우리가 약속한 PUT이다.

 

HTTP 메서드의 멱등성 (Idempotent)

여러번 호출해도 결과가 항상 똑같으면 멱등하다고 한다.
멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.

[멱등할 경우 얻을 수 있는 이점]
서버가 TIMEOUT 등으로 정상 응답을 못주었을 때,
클라이언트가 같은 요청을 다시해도 되는가에 대한 근거
(자동 복구 메커니즘)

HTTP 메서드의 캐시가능 (Cacheable)

응답결과 리소스를 캐싱하여 사용해도 되는가?
실제로는 GET,HEAD 정도만 사용

https://ko.wikipedia.org/wiki/HTTP

 

 

 

컬렉션(Collection)과 스토어(Store)

* 100% 김영한님의 강의에서 발췌하여 왔습니다.

회원관리 시스템과 파일관리 시스템의 URI 설계를 한다면
아래와 같이 설계할 수 있을 것이다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

 

아래와 같이 컬렉션(Collection) 은 서버가 리소스 URI를 결정하며,
클라이언트가 리소스 URI를 결정하여 저장하는 저장소를 스토어(Store) 라고 일컫는다.

 

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

 

 

컨트롤 URI

본래는 URI 에는 리소스만 포함되도록 하는게 이상적인 원칙이나
HTML FORM과 같은 제약이나, HTTP 메서드로 해결하기 애매한 경우에
동사로 된 리소스 경로를 사용하기도 한다.

이를 컨트롤 URI 라고 일컫는다.

최대한 리소스라는 개념으로 URI를 설계하고, 어쩔수 없을 때 사용하자.

ex) /members/new, /members/edit, /members/delete, /members/start-delivery

 

참고하면 좋은 URI 설계 개념

REST Resource Naming Guide

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

 

---

 

HTTP 응답코드 & 리다이렉션

[Network] HTTP 응답코드(Response Code)

 

 

HTTP 헤더

[Network] HTTP 헤더 정리 및 분석