Representational state transfer (REST): 데이터를 리소스로 제공
REST는 설계적 제약 조건으로 API 스스로에 대한 설명이 가능하여 수 많은 API 소비자에게 채택될 수 있도록 정의된 API 아키텍처 스타일이다.
오늘날 가장 대중적인 REST API 아키텍처 스타일은 2000년 Roy Fielding의 박사 학위 논문에 처음 소개되었다. REST API는 서버 측에서 JSON 및 XML과 같은 간단한 형식의 데이터로 표현 가능하게 한다.
REST 동작 방식
REST는 SOAP만큼 엄격하게 정의되어 있지 않다. RESTful한 아키텍처는 6개의 설계 제약 조건을 준수해야 한다.
- 일관성 있는 인터페이스: 장비 또는 애플리케이션 타입과 무관하게 목표 서버와 통신하도록 일관성 있는 통신 방법을 허용한다.
- 무상태: 요청 자체가 요청을 처리하는 데 필요한 상태이고 서버와 세션에 대한 내용을 저장하지 않는다.
- 캐싱
- 클라이언트 - 서버 아키텍처: 어느 측에서든 독립적으로 발전 가능하다.
- 애플리케이션의 계층화된 시스템
- 서버가 클라이언트에서 실행 가능한 코드를 제공 할 수 있다.
사실 REST로 구현한 서비스의 일부만이 RESTful인 경우가 있다. 그런 서비스의 핵심은 RPC 스타일로 구현되었으며, 더 큰 서비스를 리소스 단위로 분해하고, HTTP 인프라를 효율적으로 사용하고 있다. 그러나 이러한 서비스의 핵심은 HATEOAS(Hypertext As The Engine of Application State)라 지칭하는 하이퍼미디어를 사용하는 데 있다. 기본적으로 REST API는 모든 응답마다 API 사용 방법에 대한 모든 정보를 묶어 놓은 메타데이터가 담겨 있다. 이 메타데이터를 통해 클라이언트와 서버를 분리 할 수 있다. 결과적으로 API 공급자와 API 소비자 모두 통신을 방해받지 않고 독립적으로 발전할 수 있다.
"HATEOAS는 REST의 핵심기능이다. 이것이 REST를 REST 답게 만든다. 실제로 대부분의 사람들이 HATEOAS를 사용하지 않기 때문에 HTTP RPC를 사용하는 것이다." 라는 급진적인 의견이 Reddit에 올라왔다. 실제로 HATEOAS는 REST의 가장 성숙한 버전이다. 그러나 HTTP RPC를 사용하여, 요구 사항을 충족하면서도 HATEOAS를 사용한 것보다 더 고급스럽고 지능적인 API 클라이언트를 구현하기란 어렵다. 그래서, 현대의 매우 훌륭한 REST API조차 그러지 못했지만, 장기적인 관점에서 RESTful한 API 설계의 핵심으로 HATEOAS를 사용해야 된다.
서비스의 일부가 REST로 개발되고 일부는 RPC로 구현되는 경우, 실제로 REST와 RPC 사이에 gray zone이 있을 수 있다. REST는 동작과 동사 기반 대신 리소스와 명사를 기반으로 정의되어야 한다.
REST는 GET, POST, PUT, DELETE, OPTIONS, 그리고 PATCH 같은 HTTP 메서드를 사용하여 요청을 처리한다.
REST의 장점
클라이언트 - 서버 분리 클라이언트와 서버가 최대한 분리되어 있기 때문에, REST는 RPC보다 뛰어난 추상화를 제공한다. 추상화 정도가 높은 시스템일수록 세부 속성을 캡슐화하여 내부 속성을 식별하고 유지하는데 용이다하다. 이러한 특성은 안정화된 시스템을 유지하면서 REST API를 발전시킬수 있는 유연성을 제공한다.
발견 가능성 클라이언트와 서버 간의 통신은 외부 문서 없이 REST API와 상호 작용하는 방법을 이해할 수 있도록 모든 세부 사항을 설명한다.
클라이언트와 서버 간의 통신은 REST API와 상호 작용하는 방법을 이해하는 데 외부 문서가 필요하지 않도록 모든 것을 설명합니다.
캐시 지원 REST는 수 많은 HTTP 도구를 재사용가능하며 HTTP 레벨의 데이터 캐싱이 가능한 유일한 API 아키텍처 스타일다. 반대로, 다른 API 아키텍처 스타일을 통해 캐싱을 구현하기 위해서는 추가적인 캐싱 모듈이 필요하다.
다양한 형식 지원 데이터 저장과 교환을 위한 다양한 형식을 지원하는 기능으로 인해, 오늘날 공개 API를 구축하는데 REST를 가장 많이 사용하고 있다.
REST의 단점
단일 REST 구조가 없다. REST API를 구축하는 방법의 정답은 없다. 리소스를 모델링을 어떻게 할지, 모델링에 어떤 리소스를 사용할지는 상황에 따라 달라진다. 그래서 REST API는 이론적으로 구현하기 쉬울 것 같지만 실제로 어렵다.
페이로드가 많다. REST는 클라이언트가 응답을 통해 애플리케이션 상태를 이해하는데 필요한 수 많은 메타데이터를 응답에 포함한다. 이로 인해 REST API는 큰 대역폭의 요구하지만, 실제로 대규모 네트워크 파이프에서 큰 문제가 되지는 않는다. 이러한 요소는 2012년 페이스북이 GraphQL API 아키텍처 스타일을 발표한 주요한 원인이 되었다.
오버 또는 언더 패칭 문제 REST 응답에 너무 많거나 적은 데이터를 포함하는 경우, 다시 요청을 해야 한다.
REST 사용 예시
관리를 위한 API 구현. 시스템의 구성 요소 관리를 중심으로 다수의 소비자를 대상으로 하는 API가 가장 일반적인 REST API 사용 예시이다. REST는 API의 강력한 검색 성능, 체계화된 문서를 제공하는데 도움이 되며 객체 모델에도 부합한다.
간단한 리소스 기반 앱 REST는 쿼리의 유연성이 불필요한 리소스 기반의 앱을 연결하는데 유용하다.
참조: https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
