API에는 많은 방식이 있지만, 요즘 웹 개발을 진행할 때는 "REST API"를 가장 많이 사용한다.
REST API는 무엇이고, 어떻게 설계하고 사용하는 것인지 알아보자!
REST API란?
REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API!
컴퓨터 과학자인 Roy Fielding 박사가 2000년에 자신의 박사학위 논문에서 처음으로 정의한 REST는 개발자에게 비교적 높은 수준의 유연성과 자유를 제공한다. 이러한 유연성은 REST API가 마이크로서비스 아키텍처에서 컴포넌트와 애플리케이션을 연결하는 일반적인 방법으로 부상하게 된 이유 중 하나이다.
REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
REST 구성
자원 (Resource) - URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다
- 자원을 구별하는 ID는
/member/member_id/1과 같은 HTTP URI 이다
행위 (Verb) - HTTP METHOD
- HTTP 프로토콜의 Method를 사용한다
GET, POST, PUT, PATCH, DELETE
표현 (Representations)
- 클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다
- REST에서 하나의 자원은 JSON, XML, TEXT 등 여러 형태로 나타낼 수 있다
- 현재는
JSON을 주로 활용한다
REST 디자인 원칙
1. 유티폼 인터페이스 (Uniform Interface)
요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 한다.
REST API는 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의 URI에 속하는 것을 보장해야 한다. 리소스가 너무 클 필요는 없지만, 여기에는 클라이언트가 필요로 하는 모든 정보를 포함해야 한다.
2. 무상태성 (Stateless)
REST API는 무상태성의 특징을 가진다.
작업을 위해 상태 정보를 따로 저장하고 관리하지 않는다. 세션 정보다 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만 단순하게 처리하면 된다.
따라서, 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
3. 캐시 가능 (Cacheable)
REST API는 HTTP를 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있다. 따라서, HTTP가 가진 캐싱 기능을 적용할 수 있다.
서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지에 대한 정보도 포함되어야 한다.
4. 계층 구조 아키텍처 (Layered System)
클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간 매체를 사용할 수 있어 자유도가 높다.
5. 클라이언트 - 서버 구조 (Client - Server)
서버 : API 제공
클라이언트 : 사용자 인증 or 컨텍스트(세션, 로그인) 등 관리
각각의 역할이 확실히 구분되기 때문에 각 파트가 개발해야 할 내용이 명확해지고, 의존성이 줄어들게 된다.
6. Code-on-demand (Optional)
REST API 요청 시 서버에서 클라이언트로 실행 가능한 코드를 전송해서 클라이언트 기능을 확장한다
REST API 디자인 가이드
중심 규칙
- URI는 정보의 자원을 표현해야 한다
- 자원에 대한 행위는 HTTP Method로 표현한다!
주의할 점
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다
- 하이픈(-)은 URI 가독성을 높이는 데 사용
- 밑줄(_)은 URI에 사용하지 않는다
- URI 경로에는 소문자가 적합하다
- 파일 확장자는 URI에 포함시키지 않는다
accept header를 사용한다 - 리소스 간에 연관 관계가 있는 경우
/리소스명/리소스 ID/관계가 있는 다른 리소스 명 으로 표현한다
예시 :/member/{memberId}/orders
REST API 장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다
- HTTP 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다
- API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다
- 다양한 플랫폼에서 같은 내용에 대한 요구사항을 처리할 필요가 없다 (REST API를 사용하여 정보를 통합)
- 서버와 클라이언트의 역할을 명확히 분리한다
REST API 단점
- 표준이 존재하지 않는다
- HTTP Method 형태가 제한적이다
- 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다
