[TIL]HTTP 기본 정리 & REST API

배운 내용과 추가적으로 공부한 내용을 정리했습니다.

HTTP

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이다.

 

HTTP는 TCP기반 프로토콜이기 때문에 높은 신뢰성을 보장한다..

간략한 TCP 특징

1. 오류 없는 데이터 전송
2. 순서에 맞는 전달(보낸 순서대로 도착)
3. 조각나지 않는 데이터 스트림 

 

Method

서버에게 어떤 동작이 취해져야 하는지 말해주는 역할

모든 HTTP 요청 메시지는 한 개의 메서드를 가짐.

 

• GET: 서버에서 어떤 문서를 가져온다
• POST: 서버가 처리해야 할 데이터를 보낸다.
• PUT: 서버가 수정해야 할 데이터를 보낸다(전체 수정)
• PATCH: PUT처럼 수정할 데이터를 보내지만, 일부만 수정한다
• DELETE: 서버에게 리소스 삭제를 요청한다

 

응답 상태코드

서버가 받은 요청의 처리 상태를 클라이언트에게 알려주는 것

• 1xx : 정보
• 2xx: 요청 처리 성공
• 3xx: 리다이렉션
• 4xx: 클라이언트 에러 -> 클라이언트 에러
  클라이언트의 요청이 서버에서 다룰 수 없는 것일 때 발생
  401(Unauthorized): 권한 없음(인증 실패), 403(Forbidden): 요청이 서버에 의해 거부됨, 404: 리소스를 찾을 수 없음
• 5xx: 서버 에러 -> 서버에서 발생한 에러

 

HTTP 메시지

요청과 응답 2가지가 있다.

• 시작줄: 어떤 메시지인지 서술한다.
• 헤더: 속성을 담고 있다.
• 바디: 데이터를 담고 있으며, 없을 수도 있다. 

 

HTTP 커넥션

보통 하나의 웹페이지에는 다양한 리소스가 포함되기 때문에 보통 여러 번의 HTTP 요청이 필요하게 된다.

TCP 기반 프로토콜인 HTTP는 서버와 3-way handshake를 통해 커넥션을 맺는다.

 

 

 

HTTP/1.0

사진의 첫 번째 경우처럼 하나의 HTTP 트랙잭션(요청-응답)마다 커넥션을 맺기 때문에 시간이 더 소요된다.

따라서 connection: keep-alive 속성을 통해  같은 서버에 요청을 보낼 경우 커넥션을 유지시킬 수 있다.

 

HTTP/1.1

현재 쓰이는 HTTP 표준

기본적으로 지속 커넥션을 지원하기 때문에 TCP 핸드쉐이크에 드는 비용을 아낄 수 있다.

 

1.1에서는 지속 커넥션을 통해 요청을 파이프라이닝 할 수 있다.

응답이 도착하기 전에 여러 개의 요청을 큐에 쌓을 수 있기 때문에 네크워크 왕복 시간을 줄여서 성능을 높일 수 있다.

다만, HTTP 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어있지 않다.

또한 POST처럼 반복적으로 요청을 보낼 경우 문제가 생기는 요청은 파이프라이닝 하면 안된다.

 

HTTP/2.0

표준은 아니지만 많은 브라우저가 지원하고 있다.

여러 요청과 응답을 동시에 처리하기 위한 이진 프레임과 스트림을 지원하는 이진 프로토콜이다.

 

우선순위 지정

로드 프로세스 중에 콘텐츠의 우선순위를 지정하는 방법

웹 성능의 맥락에서 우선순위는 콘텐츠가 로드되는 순서를 나타냅니다

 

헤더 압축

헤더를 압축하여 효율적으로 전송하며, 헤더 필드를 이전 메시지에서 참조할 수 있도록 한다.

 

다중화(Multiplexing)

단일 TCP 연결을 사용하여 여러 요청과 응답을 병렬로 다중화하여 전송한다.

1.1의 파이프라이닝과 비슷해보이지만 훨씬 효율적이다.

 

서버 푸시

HTTP/2는 서버 푸시 기능을 제공하여 클라이언트의 요청 없이도 서버가 클라이언트에게 데이터를 전송할 수 있다.

 

 

REST API

REST는 HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처

RESTful = REST의 기본 원칙을 성실히 지킨 서비스 디자인!

 

구성

REST API는 자원, 행위, 표현 3가지 요소로 구성된다

구성 요소	내용	표현 방법
자원	자원	URI(엔드포인트)
행위	자원에 대한 행위	HTTP 메서드
표현	행위의 구체적 내용	페이로드

 

설계 원칙

1. URI는 리소스를 표현하는 것이기 때문에 동사가 아닌 명사를 사용해야 함!

2. 리소스에 대한 행위는 HTTP 메서드를 이용할 것