[REST API] 개념, 특징, URI 규칙 이해하기
▶ REST API 개념
▶ REST 구성 요소
▶ REST 특징
▶ REST API URI 설계 규칙
▶ REST API, RESTful 차이점
REST API 개념
REpresentational State Transfer
직독직해하면 표현적인 상태 전송인데...
인터넷을 통한 웹 API를 위한 표준 가운데 하나. (사실상 웹 API의 표준이라 할 수 있다.)
네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.
리소스와 HTTP메서드를 중심으로 웹 서비스를 설계하는 웹 기반의 아키텍처 스타일.
아키텍처 스타일이라는 건 시스템 구축을 위한 지침과 원칙의 집합이라는 말. 시스템의 전체 구조와 그 구조의 원칙을 정의한다.
웹 시스템을 설계할 때 어떻게 리소스를 표현하고, 어떤 메서드로 그 리소스에 접근할 것인지 등의 원칙을 제시한다.
네트워크 리소스(정보의 자원)를 URI로 표현하고,
이 리소스에 대한 CRUD 연산을 GET, POST 등의 HTTP 메서드를 통해
수행할 수 있는 아키텍처 패턴을 의미한다.
(여기서 계속 말하는 자원인 리소스는 웹에서 관리되는 모든 것을 의미. 대부분의 경우 DB에서 가져온 데이터를 기반으로 한다.)
따라서, REST API는
REST 아키텍처를 따르는 API를 말한다.
웹 서비스에 접근하기 위한 웹 API이다.
일반적으로 HTTP 프로토콜을 통해 서비스되며
JSON또는 XML형식으로 데이터를 주고 받는다.
ex) 도서관 시스템을 만든다고 가정하자.
전통적인 방법
사용자가 도서를 검색하거나 대출하려면 특정 페이지나 버튼을 클릭해
해당 기능을 수행하는 페이지로 이동.
이 때, 각 기능마다 별도의 주소(URL)가 있을 수 있다.
RESTful 방법
각 도서는 고유한 URL을 가지고 있다.
(ex) `/books/1` - 1번 도서)
도서를 검색하려면 해당 URL로 `GET`요청을 하고,
도서를 대출하려면 해당 URL로 `POST`나 `PUT` 요청을 한다.
즉, 도서 자체가 하나의 '리소스'로 표현되며,
그 리소스에 대한 다양한 '행동'이 HTTP 메서드로 정의된다.
REST 구성 요소
자원 (Resource) : URI
- URI는 자원을 표현하는데 집중한다.
- 모든 자원은 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 `/books/1`와 같은 HTTP URI이다.
- Client는 URI를 이용해서 자원을 지정하고, 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
행위 (Verb) : HTTP Method
- 행위에 대한 정의는 HTTP METHOD를 통해 한다.
- HTTP 프로토콜의 Method를 사용한다.
- HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE 와 같은 메서드를 제공한다.
표현 (Representation of Resoucre)
- Client가 자원의 상태(정보)에 대한 조작을 요청하면
Server는 이에 적절한 응답(Representation)을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태로 Representation으로 나타내어 질 수 있다.
- JSON혹은 XML을 통해 데이터를 주고 받는 것이 일반적이다.
REST 특징 (REST API를 디자인할 때 고려해야 할 핵심 원칙들)
1. Server-Client (서버-클라이언트 구조)
- 자원이 있는 쪽이 Server,
자원을 요청하는 Client가 된다.
REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고,
Client는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다.
2. Stateless (무상태)
- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
- Client의 context를 Server에 저장하지 않는다.
즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
- Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
각 API 서버는 Client의 요청만을 단순 처리한다
즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다. (DB에 의해 바뀌는 것은 허용)
- Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아진다.
3. Cacheable (캐시 처리 가능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
- 대량의 요청을 효율적으로 처리할 수 있다.
4. Layered System (계층 구조)
- Client는 REST API Server만 호출한다.
- REST Server는 다중 계층으로 구성될 수 있다.
보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다.
Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
하지만, Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없다.
5. Uniform Interface (인터페이스 일관성)
- URI로 지정한 Resource에 대한 요청을 통일되고,
한정적으로 수행하는 아키텍처 스타일을 의미한다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용가능하며, Loosely Coupling(느슨한 결함) 형태를 갖는다.
즉, 특정 언어나 기술에 종속되지 않음
6. Self-descriptiveness (자체 표현 구조)
- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다.
REST API URI 설계 규칙
1. URI는 정보의 자원을 표현해야한다. (자원(Resoure)명은 동사보다는 명사를 사용)
/books/delete/1
이렇게 사용한다면 REST를 제대로 적용하지 않은 URI이다.
URI는 자원을 표현하는데 중점을 두어야한다.
delete와 같은 행위에 대한 표현이 들어가면 안된다.
2. 자원에 대한 행위는 HTTP Method로 표현
만약 자원의 삭제에 대한 api를 만든다고 가정하면
DELETE HTTP Method를 사용하여 /books/1 이렇게 URI를 표현하면 된다.
그럼 1번 책을 삭제하는 메서드의 의미가 되는 것이다.
3. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
4. URI 마지막 문자는 슬래시(/)를 포함하지 않는다.
5. 하이픈 (-) 은 URI 가독성을 높이는데 사용
6. URI 경로에는 소문자가 적합하다.
7. 파일 확장자는 URI에 포함시키지 않는다.
8. 자원을 표현할 때 Collection과 Document 사용
Collection은 문서들의 집합, 객체들의 집합으로 복수로 표현하고
Document는 하나의 문서, 한 객체로 단수로 표현
ex)
/books/novel/1
책이라는 컬렉션과
소설 카테고리를 의미하는 도큐먼트와
1번 책을 의미하는 도큐먼트로 구성된 URI.
REST API, RESTful 차이점
REST API
REST 아키텍처 스타일에 따라 구성한 API이다.
RESTful API
HTTP를 위한 아키텍처 스타일 중 하나로
REST의 설계 규칙을 잘 지켜서 설계된 API이다.
REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭된다.
이렇게 RESTful API는 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로.
만약, 성능이 중요한 상황이라면 굳이 RESTful 한 API를 구현할 필요는 없습니다.
결론적으로는 RESTful API는
REST API의 원칙을 따르기 때문에
REST API보다는 조금 더 RESTful 하다고 볼 수 있다.
* 개인적으로 공부하며 기록중입니다.