학습 목표
- Rest API란
- REST 구성
- Rest 아키텍처 스타일
REST (REpresentational State Transfer)
- REST API는 인터넷 상에서 시스템들 간의 상호 운용성을 제공하는 방법 중 하나
- REST 아키텍처 스타일을 따르는 API
- 데이터 요청이 REST API로 전송될 때에는 일반적으로 HTTP를 통해서 이루어진다
- REST 스타일로 설계된 API가 HTML, XML, 일반 텍스트, JSON과 같은 다양한 형식으로 메시지를 반환할 수 있다. 여기서 JSON 포맷이 어떠한 프래그래밍 언어로든 읽을 수 있고 경량화가 되어 있기 때문에 선호되는 메시지 포맷이다.
REST 구성
- 자원(Resource) == URI
- 행위(Verb) == Http Method
- 표현(Representation)
REST 아키텍처 스타일
RESTful API는 다음과 같은 가이드를 준수해야 REST API라고 할 수 있다.
- Client-Server 구조
- Stateless(무상태성)
: 상태정보를 저장하거나 관리하지 않는다. 세션 정보나 쿠키 정보를 별도로 저장하거나 관리하지 않기 때문에 서버는 단순히 들어오는 요청만 처리하면 된다. - Cache
: Client-Server 간에 캐싱 기능 적용이 가능하다. HTTP 표준에서 사용하는 Last-Modified태그, E-Tag를 이용하면 캐싱 구현이 가능하다 - Uniform Interface
: URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다 - Layered System
: REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드밸런싱, 암호화 계층을 추가하여 구조상 유연성을 가질 수 있고, Proxy, Gateway 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다 - Code-On-Demand(선택 사항)
: 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트의 기능을 확장할 수 있는 기능
Uniform Interface 특징
-
Identification of resources
: 자원의 식별, 요청 내에 기술된 개별 자원을 식별할 수 있어야한다. 이 말은 웹 기반 REST 시스템에서 URI 사용을 예로 들 수 있는데 서버에서는 DB를 통해서 데이터 레코드들을 HTML, XML, JSON 같은 형태로 반환하는 것을 말한다 -
manipulation of resources through representations
: 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것을 통해 서버의 자원을 변경/삭제할 수 있는 충분한 정보를 가지고 있다 -
self-descriptive messages
: 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 서버에서 반환한 메시지를 어떤식으로 처리해야 되는지에 대한 설명을 포함하는 것을 말하며 반환된 메시지만으로는 클라이언트가 무엇을 처리해야하는지에 대해 충분히 알려주지 못하기 때문이다 -
hypermedia as the engine of application state (HATEOAS)
: 클라이언트가 관련된 리소스에 접근하기를 원한다면 하이퍼미디어 링크를 통해 상태 변화가 가능해야하고 링크 정보를 동적으로 바꿀 수 있다
REST 아키텍처 스타일을 모두 지켜야 하는가?
- 실제로 시스템을 개발하다보면 이러한 규칙을 모두 준수하기가 힘들다
- REST API라고 부를려면 적어도 Uniform Interface, 특히 self-descriptive message, HATEOAS 조건은 준수하자
- 위 조건을 만족하지 못한다면 그 API는 REST API라고 부르기 힘들기 때문에 HTTP API라고 부를 수 있다
참고
만사가 귀찮은 ISFP가 쓰는 학습 블로그