REST API란?
REST API이란?
REpresentational State Transfer의 약어로, 웹 시스템을 외부에서 이용하기 위한 프로그램을 호출하는 규약(API) 종류의 하나이다. REST이라고 불리는 설계 원칙에 따라 책정된 것이다. REST는 적용 범위가 넓은 추상적 모델이지만, 일반적으로 REST의 원칙을 Web API에 적용한 것을 RESTful API라고 부르고 있다.
RESTful API에서는 URL/URI로 모든 리소스를 고유하게 식별하여, 섹션 관리나 상태 관리 등을 하지 않는다. 동일한 URL에 대해서는 항상 동일한 결과가 반환되는 것이 기대된다.
또한, 리소스의 조작은 HTTP 메소드에 따라 지정(취득은 GET메소드, 쓰기는 POST 메소드)되며, 결과는 XML이나 HTML, JSON형식 등으로 반환된다. 또한 처리 결과는 HTTP 상태 코드로 통지하는 원리가 포함되어 있다.
REST의 네 가지 설계 원칙
REST의 네 가지 설계 원칙은 다음과 같다.
- 섹션등의 상태 관리를 하지 않다(주고 받는 정보는 그 자체로 완결되어 해석될 수 있다).
- 정보를 조작하는 명명의 체계가 미리 정의, 공유되어 있다(HTTP의 GET이나 POST 메소드 등).
- 모든 정보는 범용적으로 구문으로 식별된다(URL이나 URI등).
- 정보의 내부에 다른 정보나 그 정보의 다른 상태으로의 링크를 포함하는 것이 가능하다.
리소스에 대해서는 URL가 대응할 수 있다(그 때문에 URL이 명사적으로 되는 것이 많다).
REST한 API와 그렇지 않은 API의 예
유저 정보를 작성, 획득, 삭제하는 시스템을 생각해보자.
보통 REST한 설계 아이디어로 시스템을 구축하지 않은 사람이라면 아래의 이미지와 같이 처리에 URL이 대응하도록 시스템을 구상할 것이다.
예를 들어, 갱신을 할 때 갱신용 URL을 발행하여 섹션 등에 유지된 정보를 이용하여 리퀘스트 처리를 실시한다. 그러나 이것은 REST한 API가 아니다. REST한 API는 리소스에 대응하는 URL이 정해져 있다. 처리에는 URL가 대응할 수 없다.
그러나 REST한 API는 유저 정보(위 화면 오른쪽 DB의 UserInfo)에 URL가 대응한다. REST한 아이디어를 동일한 시스템을 구축한 경우는 아래의 그림과 같이 된다.
위 그림으로 알 수 있듯 동일한 처리(유저의 정보 작성, 취득, 갱신, 삭제)가 하나의 "/UserInfo" URL에 대응하게 된다.
https://hogehoge.com/userInfo/1/유저 ID등은 "/UserInfo" 와 함께 URL에 포함하여 시스템 쪽에 전달하고 있다. 작성, 삭제, 갱신, 삭제에 대해서는 HTTP의 일반적인 리퀘스트 메소드를 사용하여, GET이라면 취득, POST라면 작성, PUT이라면 갱신, DELETE라면 삭제와 같은 처리가 결정된다. HTTP의 일반적인 리퀘스트 메소드를 사용하는 것도 REST한 API의 하나의 요소이다.
장점과 단점
장점
- 어플리케이션내의 리소스가 URI로 표시할 수있다.
- 주소란에 입력하면, 그 리소소를 참고할 수 있다.
- 어떤 리소스를 조작하려고 하는지 알기 쉽다.
- 주소란에 입력하면, 그 리소소를 참고할 수 있다.
- URI에 규약에 생기는 것으로 사용하는 개발자가 편안해진다.
- 장래 상정되는 시스템 규모의 확대 대응이 가능한 설계이다.
- stateless하게 되는 것으로 확장성이 향상된다.
- 액세스 집중에 견디기 쉬운 구조가 된다.
- 통합이 상대적으로 쉽다.
- 표준 데이터 포맷(XML이나 JSON)을 취급함으로써, 다른 시스템과의 연계가 용이해진다.
- REST에 근거한 WEB 어플리케이션에서는 인터페이스가 고정되어 있으므로 호환성의 문제가 발생하지 않는다.
- 표준 API의 제공
- RESTful API를 공개함으로써 표준 데이터 포맷을 사용하여 다양한 애플리케이션에 제공할 수 있다.
단점
- 프로그래밍 언어는 리소스 지향이 아니므로, URI와 매핑하는 코드가 더러워질 수 있다.
- REST API를 하이퍼 텍스트 구동으로 하는 것은 비교적 어렵다.
참고자료