REST 아키텍처 & HTTP 메세지

1. REST(Representational State Transfer) 

 

- REST는 분산 하이퍼미디어 시스템(ex: 웹)을 위한 소프츠웨어 아키텍처의 한 형식으로, 시스템의 모든 것을 자원(Resource)으로 규정하고, 이 자원의 상태를 JSON/XML 등의 표현 형태(Representation)로 클라이언트와 서버가 주고받는 방식(CRUD, HTTP Method)을 말합니다. 

-> REST 애플리케이션 계층의 제약 조건에는 총 6가지가 있습니다.

1️⃣ Uniform interface: 클라이언트 서버 간 인터페이스가 일관되고 표준화되어야만 합니다. Resource 기반(URI 식별자), Representaion으로 전송, Self-descriptive message(Content-Type: application/json)의 요청•응답 헤더, HATEOAS(자주 사용되지 않지만 하이퍼링크 기반으로 탐색 가능한 시스템을 만드는 REST의 최종 단계) -> API 사용 방법을 표준화

//[1] Resource
/users
/posts

//[3] Self-descriptive message
Content-Type: application/json

//[4] HATEOAS
{
  "user": "soo",
  "links": {
    "posts": "/users/1/posts" //(응답에 다음 행동 링크 포함)
  }
}

2️⃣ Client-server: 클라이언트와 서버를 명확히 분리되어야하며, 서로 독립 발전 가능 상태여야합니다. 탈동조화(Decoupling)이 되어야지만 유연성, 확장성 면에서 좋습니다.
3️⃣ Stateless: 서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리되어야합니다. 요청 하나는 완전한 정보를 담고 있으며 로그인 상태와 같은 것들을 기억하지 않기 때문에 이런 기억 정보는 헤더 넣어줘야합니다. 

4️⃣ Cacheable: 응답은 캐싱 가능 여부를 명시해야하며, 캐시를 통한 성능 향상이 가능합니다. 클라이언트 쪽인 브라우저, CDN, 프록시 서버가 캐싱을 해둔 뒤 속도나 서버 부하 면에서 장점을 가집니다. 

5️⃣ Layered system: 클라이언트는 자신이 중간 서버를 거치는지 알 필요가 없습니다. 중간 레이어 역할인 API Gateways나 캐시서버 등의 다양한 레이어를 그냥 하나의 서버로 인식합니다.

6️⃣ Code on demand ( optional ) : 서버는 필요 시 클라이언트에게 실행 가능한 코드를 전달할 수 있습니다. 서버가 JS 코드를  내려줍니다. 이 제약 조건은 옵션으로, 사용하지 않아도 RESTful 가능합니다. 현대 SPA 구조와 맞지 않아서 사용되지 않습니다.

-> 이를 설계하고 준수하여 구축된 시스템을 RESTful API(REST API가 적용돼 구현된 것)로 부릅니다. 하지만 SPA 구조 때문에 위에서 설명됐던 Uniform interface의 HATEOAS는 링크를 포함하는 구조이기 때문에 실질적으로 구현 때 자주 무시됩니다. 

 

- Resource(자원)&HTTP Method(행위): REST 아키텍처 설계의 가장 핵심적인 문법은 명사(자원)과 동사(행위)를 엄격하게 분리하는 조합입니다. 전통적인 RPC 방식에서는 엔드포인트 자체에 행위가 포함되어있엇습니다.(ex. POST /getMovieDetail?id=1) 하지만 REST 아키텍처에서는 URI는 오직 식별자로써, 복수형 명사로 계층적 표현합니다.(ex. DELETE /movies/123) 행위는 HTTP Method인 GET, POST, PUT/PATCH, DELETE로 표현합니다.

* RPC(Remote Precedure Call)은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술을 의미합니다.

[개념] RPC(Remote Procedure Call)의 개념 및 특징

 

 

- 연결성(Connection)과 상태(State)는 각각 웹 통신의 기반인 네트워크 계층(TCP/IP)과 애플리케이션 계층(HTTP/REST)의 개념입니다.

-> 네트워크 계층(물리적 연결)에서는 비연결성과 지속 연결이 있습니다. 비연결성(Connectionless)은 HTTP/1.0의 기본 동작 방식으로, 요청-응답 1세트가 끝나면 즉시 TCP 연결을 끊어버리며 서버 자원을 아껴 핸드쉐이크 비용이 발생하여 속도가 저하됩니다. 지속 연결(Persistent Connection)은 HTTP/1.1부터 도입된 방식으로, 한번 맺은 TCP 연결을 일정 시간 유지하여 연속적인 데이터 교환 시 성능을 최적화합니다. 

-> 애플리케이션 계층에서는 상태유지와 무상태성이 있습니다. 상태 유지(Stateful)는 서버가 클라이언트의 식별 정보나 작업 진행 상황을 메모리에 계속 기억하는 아키텍처입니다. 무상태성(Stateless)는 서버가 클라이언트의 컨텍스트를 전혀 기억하지 못하며, 각각의 요청은 독립적으로 모든 문맥이 포함됩니다. 현재 API  서버는 무상태성을 지향하지만 상태 유지를 해야하는 도메인이 존재하는데 그 예시로는 웹소켓(실시간 양방향 서비스)나 전통적인 세션 기반 인증 등이 있습니다.

 

Q. 지속 연결과 웹소켓은 어떤 차이가 있는건가요?
A.  지속 연결과 웹소켓은 물리적이 네트워크 파이프를 열어둔다는 점에서 유사해보이지만 완전히 다른 기술입니다. 지속 연결은 3-Way Handshake의 물리적 비용을 줄이기 위한 최적화 기법입니다. TCP 파이프를 끊지 않고 일정 시간 재사용하지만 단방향 요청-응답 모델을 그대로 유지하기 때문에 서버가 일방적으로 데이터를 보낼수 없습니다. 하지만 웹소켓의 경우, 양방향 실시간 통신을 구현하기 위한 독립적인 프로토콜로, 초기 연결 시에는 HTTP 프로토콜을 사용하여 핸드쉐이크를 수행하지만 프로토콜을 업그레이드합니다. 이 연결이 수립되면 클라이언트의 요청이 없어도 서버가 클라이언트에게 먼저 데이터를 밀어넣는 것이 가능해집니다. 이 상태의 연결이 Stateful 연결이라고 합니다.

 

- API Server Architecture는 이전에 설명한  CSR과 유사한 구조로, 렌더링을 클라이언트 쪽에서 책임을 지고 서버는 순수 데이터( JSON)의 가공과 영속성 관리에만 집중하는 서버 아키텍처입니다. 

 

2. HTTP 메세지

- HTTP 통신에 예외 없이 적용되는 글로벌 표준 규약으로, 헤더와 바디의 단순한 2분할이 아니라 4단게 물리적 구조를 갖습니다. 

(1) 시작 줄(Start Line) :  메세지의 가장 첫 번째 줄로, 통신 목적이나 결과를 요약합니다. 요청 메세지(Request)는 HTTP 메서드+목적지 URI+프로토콜 버전이 들어가며 응답 메세지(Response)는 프로토콜 버전+HTTP 상태 코드+상태 텍스트 구성됩니다.

Requset: GET /api/movies HTTP/1.1
Response: HTTP/1.1 200 OK

(2) 헤더(Header): 시작 줄 다음으로 이어지며 클론을 사용하여 키-값으로 메타데이터를 나열합니다. 

(3) 빈줄(CRLF): 헤더의 입력을 끝났음을 네트워크 파서에게 알리는 매우 중요한 시스템적 규칙으로, 시스템은 여기서부터 바디(실제 데이터)라고 판단합니다.
(4) 본문(Body/Payload) : 빈줄 이후에 등장하는 실제 전송 데이터로, JSON 문자열, HTML 문서, 이미지 바이너리 파일 등이 담깁니다.

 

- 항상 바디가 존재하지는 않습니다. GET 요청(조회), DELETE 요청(삭제), 204 No Content 응답의 경우에는 바디가 없이 전달됩니다. 

 

- HTTP 버전에 따라 전송 구조가 달라졌습니다. HTTP/1.1 시대에서는 헤더와 바디가 사람이 있을 수 있는 텍스트 문자열로 전송되었다면, HTTP/2 및 HTTP/3 시대에서는 이 텍스트 패키지를 컴퓨터가 빠르게 처리할 수 있는 이진수로 잘개 쪼개 보낸 뒤 브라우저나 스프링 부트에서 다시 규격화하여 Response, Request 객체로 조립합니다.