HTTP가 뭐예요? (REST)

지난 포스트를 통해 우리는 HTTP의 특징과 요청, 응답 시에 HTTP Message 구조를 알아보았습니다.

2022.10.07 - [분류 전체보기] - HTTP가 뭐예요? (HTTP의 특징과 구조)

HTTP가 뭐예요? (HTTP의 특징과 구조)

오늘은 REST (Representational State Transfer)에 대해 알아보도록 하겠습니다.

• REST

REST (Representational State Transfer)는 2000년 Roy Fielding에 의해 최초로 소개되었으며, ROA (Resource Oriented Architecture)를 따르는 웹에서 데이터를 전송하고 처리하는 방법을 정의한 웹 서비스 아키텍처입니다.

REST는 HTTP URI (Uniform Resource Identifier)를 통해 자원을 명시하고, HTTP Request method를 통해 해당 자원에 대한 CRUD Operation을 적용합니다.

즉 REST의 설계 중심에는 항상 자원 (Resource)가 있으며 HTTP Request method를 통해 자원을 처리, 조작하도록 설계된 아키텍처를 의미합니다.


REST 구성 요소

• Resource (URI)

모든 자원에는 HTTP URI로 구분되는 고유한 ID가 있으며, 이 자원은 Server에 존재합니다.

Client는 URI를 이용해서 자원을 요청하고 해당 자원의 정보에 대한 조작을 Server에 요청합니다.

• Verb (HTTP Reqeust method)

HTTP Request method를 사용하며 GET, POST, PUT, DELETE 등이 있습니다.

• Representation

Client가 자원의 정보에 대해 조작을 요청하면 Server는 이에 적절한 응답 (Representation)을 보냅니다.

REST에서 자원은 JSON, XML, TEXT, RSS 등으로 표현되며 일반적으로 JOSN과 XML을 사용합니다.


REST의 조건
다음 조건을 준수하는 한 개별 컴포넌트는 자유롭게 구현할 수 있습니다.

• Server/Client 구조

Server는 자원을 가지고 있으며 이를 조작하는 방법을 API를 통해 제공합니다.

Client는 API를 통해 자원을 요청, 조작하며 사용자 인증이나 세션, 로그인 정보 등을 직접 관리합니다.

이러한 구조는 Server와 Client가 서로 의존적이지 않게 하며 독립적으로 발전이 가능하게 합니다.

• Stateless (무상태성)

REST는 HTTP에 기반을 두므로 역시 Stateless 해야 합니다.

Client는 context를 Server에 저장하지 않으며, Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.

• Cacheable (캐시 처리)

REST는 HTTP의 캐싱 기능을 적용할 수 있으며, 이는 대량의 자원 요청을 효율적으로 처리하기 위해 사용됩니다.

캐시를 사용함으로써 Server는 Client의 요청에 빠르게 응답할 수 있습니다.

• Layered system (계층화)

계층적 구조는 각 구성 요소가 상호 작용하는 계층 이외의 구조는 볼 수 없도록 제한하며 이는 각 계층을 캡슐화시키도록 구성해야 합니다.

• Code On Demand (Optional)

Server로부터 받아온 Script를 Client에서 실행할 수 있어야 합니다.

이는 필수는 아닙니다.

• Uniform Interface (인터페이스 일관성)

API를 제공할 때는 자원에 대한 균일한 인터페이스를 결정해야 하며 이를 위해 아래 4가지 제약을 따라야 합니다.

Identification Of Resources (리소스 식별)
URL을 사용하여 API에 접근하는 자원을 식별할 수 있어야 합니다.

즉 모든 자원은 URL를 통해 식별이 가능해야 합니다.

Manipulation Of Resource through Representations (표현을 통한 자원 조작)
특정 자원을 나타내는 URL을 바꾸지 않고도, 표현 (Representation)을 이용하여 자원을 조작할 수 있어야 합니다.

표현의 종류로는 HTTP Request method, Content type 등이 있습니다.

Self-descriptive messages (자기 서술적 메시지)
요청과 응답 모두 메시지 그 자체만으로도 목적과 의미를 파악할 수 있도록 충분한 정보를 가지고 있어야 합니다.

hypermedia as the engine of application state (HATEOAS)
애플리케이션의 상태가 하이퍼링크를 통해 전이되어야 합니다.

• REST API

REST를 기반으로 설계된 API를 우리는 REST API라고 부릅니다.

REST API 설계 기본 규칙

• URI는 자원을 중심으로 표현해야 합니다.
• 자원에 대한 행위는 HTTP Request method로 표현해야 합니다.

GET /members/delete/1

위와 같은 방식은 delete라는 행위에 대한 표현 URI에 들어갔으므로 REST 하다고 할 수 없습니다.

위의 잘못된 URI를 설계 기본 규칙에 따라 수정하면 아래와 같습니다.

DELETE /members/1

REST API URI 설계 규칙

• 소문자를 사용합니다.

GET /MEMBERS/1 (x)
GET /members/1 (o)

• 언더바대신 하이픈을 사용합니다.

POST /members/my-friend (x)
POST /members/my_friend (o)

• URI의 마지막에는 슬래시를 넣지 않습니다.

GET /members/friends/ (x)
GET /members/friends

• 계층 관계를 나타낼 때는 슬래시를 구분자로 사용합니다.

GET /members/male-friends (x)
GET /members/male/friends (o)

• 파일 확장자는 URI에 포함시키지 않습니다.

GET /members/friends/name.json (x)
GET /members/firends/name      (o)

• 자원은 기본적으로 명사를 사용하며, 자원의 조작을 의미하는 경우 예외적으로 동사를 허용합니다.

POST /members/friends/info/writing (x)
POST /members/firends/info/write   (o)

• URI에 작성되는 영어는 복수형으로 작성해야 합니다.

GET /member/name  (x)
GET /members/name (o)

• RESTful

REST의 설계 원칙을 충족하여 설계된 API를 우리는 RESTful 하다고 지칭합니다.

RESTful 한 API란 그 자체만으로 이해하기 쉬우며 호환성을 높이는 것에 목적이 있습니다.







여기까지 REST에 대해 알아보았습니다.



구독과 좋아요 그리고 생산적인 댓글은 언제나 환영입니다.