왜 이런 방식으로 설계되는가
REST API는 웹과 백엔드 개발에서 가장 널리 사용되는 통신 방식이다. 많은 서비스가 REST API를 기반으로 동작하지만, 왜 이런 규칙과 제약을 따르는지에 대해서는 막연하게 이해하는 경우가 많다. 이 글에서는 REST API의 기본 개념과 설계 배경을 중심으로 정리한다.
REST란 무엇인가
REST는 Representational State Transfer의 약자다. 네트워크 상에서 자원을 어떻게 표현하고 전달할 것인지를 정의한 아키텍처 스타일이다. REST는 특정 기술이나 프로토콜이 아니라, 웹의 구조를 잘 활용하기 위한 설계 원칙에 가깝다.
REST의 핵심은 다음과 같다.
- 자원을 중심으로 설계
- 상태를 표현으로 전달
- HTTP를 기반으로 한 일관된 인터페이스
REST API란 무엇인가
REST API는 REST 원칙을 따르는 API를 의미한다. 클라이언트와 서버는 HTTP 요청과 응답을 통해 통신하며, 요청은 자원에 대한 행위를 표현한다.
REST API의 기본 구성 요소는 다음과 같다.
- 자원(Resource)
- 행위(Method)
- 표현(Representation)
이 세 가지가 조합되어 API가 설계된다.
자원 중심 설계
REST에서는 API를 기능이 아니라 자원 기준으로 설계한다.
예를 들면 다음과 같다.
- 사용자 목록
- 주문 정보
- 상품 데이터
자원은 보통 URI로 표현되며, 동사가 아닌 명사 형태로 정의된다.
HTTP Method의 역할
자원에 대한 행위는 HTTP Method로 표현한다.
대표적인 Method는 다음과 같다.
- GET: 자원 조회
- POST: 자원 생성
- PUT: 자원 전체 수정
- PATCH: 자원 부분 수정
- DELETE: 자원 삭제
URI는 자원을 표현하고, Method는 행위를 표현하는 구조가 REST 설계의 핵심이다.
상태를 저장하지 않는 구조
REST는 무상태(Stateless) 구조를 지향한다. 서버는 이전 요청의 상태를 저장하지 않고, 각 요청은 독립적으로 처리된다.
이를 통해 다음과 같은 장점이 있다.
- 서버 확장성 향상
- 요청 처리 단순화
- 로드밸런싱 용이
클라이언트는 요청에 필요한 모든 정보를 포함해 전달해야 한다.
일관된 인터페이스
REST는 일관된 인터페이스를 강조한다. 같은 자원에 대해 항상 같은 방식으로 접근할 수 있어야 한다.
일관성이 유지되면 다음과 같은 효과가 있다.
- API 사용법 예측 가능
- 문서 의존도 감소
- 유지보수 용이
이 일관성은 REST의 가장 중요한 가치 중 하나다.
REST API를 사용하는 이유
REST API가 널리 사용되는 이유는 명확하다.
- HTTP 기반으로 접근성이 높음
- 다양한 클라이언트와 호환 가능
- 단순하고 확장 가능한 구조
- 캐시, 프록시 등 웹 인프라 활용 가능
특히 웹과 모바일 환경에서 REST는 표준적인 선택지로 자리 잡았다.
REST API 설계 시 자주 발생하는 오해
REST API를 설계할 때 다음과 같은 오해가 자주 발생한다.
- URI에 동사를 포함
- HTTP Method를 무시한 설계
- 상태를 서버에 저장하는 구조
이러한 설계는 REST의 장점을 약화시킬 수 있다.
REST API는 언제 적합한가
REST API는 다음과 같은 경우에 적합하다.
- 웹과 모바일 클라이언트가 함께 사용하는 서비스
- 리소스 중심의 데이터 모델
- 비교적 단순한 요청과 응답 구조
반대로 복잡한 실시간 통신이나 고성능 바이너리 통신이 필요한 경우에는 다른 방식이 더 적합할 수 있다.
REST와 다른 통신 방식의 관계
REST는 유일한 선택지는 아니다.
- gRPC
- GraphQL
- WebSocket
각 방식은 목적과 특성이 다르며, REST는 범용성과 단순성을 중시하는 선택지다.
정리
REST API는 자원을 중심으로 설계하고, HTTP의 특성을 최대한 활용하는 아키텍처 스타일이다. 단순한 규칙처럼 보이지만, 확장성과 유지보수를 고려한 구조적 이유가 존재한다. REST의 개념을 이해하면 API 설계와 사용 방식에 대해 더 명확한 기준을 가질 수 있다.