REST API(Representational State Transfer API)

5초 이해

---

REST API는 클라이언트가 서버의 데이터를 조회하거나 변경할 떄 사용하는 약속된 요청 방식이다.

상황으로 이해하기

---

💡 쇼핑몰에서 상품을 조회하고 주문하는 경우를 생각해보자

REST API가 없는 경우

• FE, BE 가 데이터를 주고받는 방식을 개발자끼리 일일이 협의해야함
• 상품 조회, 주문 생성, 주문 취소를 어떤 주소와 어떤 요청 방식으로 처리할지 일관된 규칙이 없을 수 있음

 

REST API를 사용하는 경우

• 빨간색은 어떤 요청 방식(HTTP 메서드)인지
• 파란색은 어떤 자원(URL)에 접근할 것인지

Client Action	HTTP Request	Server Action
상품 목록 조회	GET /products	상품 목록 반환
상품 상세 조회	GET /products/10	10번 상품 반환
주문 생성	POST /orders	새로운 주문 생성
주문 취소	GET /orders/5

핵심은 자원(Resource)를 URL로 표현하고, HTTP 메서드로 수행할 동작을 구분하는 것이 REST API 설계의 대표적인 모습이다.

 

REST API가 없다고 데이터 통신이 불가능한 것이 아니다. REST는 여러 API 설계 방식 중 하나일 뿐이다.

 

정확한 정의

---

REST API는 REST 아키텍처 스타일의 제약조건을 따르도록 설계된 API이다.

 

자원을 URI로 식별하고, 일반적으로 HTTP 메서드를 통해 자원에 대한 작업을 수행하며, 표현(Representation)을주고받는다. 클라이언트-서버 분리, 무상태성(stateless), 캐시 가능성, 계층화 시스템, 일관된 인터페이스 등의 제약을 따른다.

 

Keyword

• Resource: API가 다루는 대상 자원
• URI(Uniform Resource Identifier): 인터넷에서 특정 자원을 고유하게 식별하기 위한 구분자(URL은 URI의 한 종류임)
• Stateless: 각 요청이 독립적으로 처리될 수 있도록 필요한 정보를 포함하는 특성

 

Pain Point

HTTP는 통신 프로토콜이고, REST API는 설계하는 아키텍처 스타일이라는 것을 잊지말자

구분	HTTP	REST API
범주	통신 프로토콜	API 설계 방식
역할	Request(요청)과 Response(응답)을 주고 받는 규칙 제공	리소스(자원)을 어떻게 식별하고, 조작할지 설계
주요 요소	Method, Header, Body, Status Code(상태코드)	Resoucre, URI, Representation, Stateless
관계	REST 없이도 사용 가능 (통신 규칙이니까)	일반적으로 HTTP를 활용함(통신 규칙이 아닌, 해당 통신에서 어떻게 자원 식별 · 조작할지가 핵심)

 

도식화

---

 

다시 한 번, 강조한다. HTTP는 데이터를 주고 받는 통신 규칙(프로토콜)이라면,

 

REST API는 그 통신을 활용해

서버의 자원을 일관되게 다루도록 설계한 API이다.