REST
REST(Representational State Transfer; 상태 표현 전달)란, 서버와 클라이언트 사이 자원을 주고받는 형식이며 소프트웨어 아키텍처 디자인 가이드라인이다.
쉬운 예로, 웹 서버에 특정 URL로 접근하여 HTML 페이지나 이미지 등의 자원을 전달받기 위해서는 REST 규칙을 준수하여 아키텍쳐를 구축해야 한다.
프로토콜 개념과 비슷하지만, 규칙의 체계가 아닌 모음집이라는 점에서 프로토콜로 분류되지 않는다. W3C(World Wide Web Consortium)에서 유지관리하는 SOAP(Simple Object Access Protocol) 데이터 전송 방식 프로토콜과는 구분이 필요하다.
일반적으로 활용 목적과 개발자의 선호에 따라 REST 또는 SOAP를 준수하여 API를 제작한다.
REST의 기원
REST란 용어는 2000년 Roy Fielding의 박사 논문에서 well-designed된 웹 애플리케이션을 설명하기 위해 처음 사용되었다. 1993년 부터 웹의 수요가 늘어남에 따라 기업간의 웹 인터페이스 프로토콜이 필요해졌고, W3C와 IETF(Internet Engineering Task Force)의 협업 아래 URI, HTTP, HTML 등을 정의하였다. Roy Fielding도 함께 프로젝트를 진행하였는데, 이 경험을 토대로 인터넷 인터페이스 프로토콜을 따르기 위한 소프트웨어 아키텍쳐 가이드라인을 제시하였다.
REST의 Architectural Properties
REST가 제안하는 아키텍쳐 제약사항은, 결과적으로 다음과 같은 특징을 가지는 아키텍쳐를 설계하도록 돕기 위해 제시되었다.
Performance: 사용자 입장의 성능과 네트워크 효율성
Scalability: 방대한 시스템 내에서 이루어지는 구성요소 간 상호작용의 관리
Simplicity: 일관적이고 간결한 인터페이스
Modifiability: 애플리케이션이 작동 중임에도 가능한 시스템 구성요소 교체
Visibility: 시스템 구성요소 간의 표면적, 가시적 소통
Portability: 다양한 환경에 대한 코드와 데이터의 높은 이식성
Reliability: 시스템 구성요소, 커넥터, 데이터 등 시스템 레벨의 failure에 대한 저항력
REST의 Architecture Constraints
REST는 6가지 아키텍쳐 가이드라인을 제시한다.
Client–server architecture
Client와 Server 디자인 패턴을 통해 자원 관리와 저장에 대한 책임을 분리한다. 이를 통해 Server 구성의 simplicity, scalability를 보장받으며, 방대하고 변칙적인 인터넷 환경과 독립성을 가질 수 있다. (독립성은 곧 anarchic scalability(탈중앙적 확장성)이다.)
Statelessness
stateless란, 일반적으로 Server인 공급자측에서 세션 정보가 관리되지 않는 상태를 뜻한다. stateless 환경에서 일반적으로 Client인 소비자는 자신이 전송하는 모든 요청 패킷에 context 정보를 담아 이전 전송된 패킷의 정보 없이도 공급자가 요청을 관리하고 권한을 부여할 수 있도록 한다. 이는 high-volume 애플리케이션에서 공급자의 세션 정보로 인한 부담을 줄여주고, performance를 강화시킨다.
Cacheability
World Wide Web에서의 Client들과 중간 제공자들은 응답을 캐싱할 수 있다. 공급자의 응답을 기반으로 하여 Client가 부적절하게 요청하는것을 막기 위해, 암묵적 또는 명시적으로 cashable, non-cashable 형태로 정의되어야 한다. Well-managed 캐싱은 몇몇의 Client-Server 상호작용을 제거해주기 때문에 scalability와 performance를 증가시킨다.
Layered system
Client-Server 레이어 구조의 시스템에서는, Client가 특정 서버에 연결 되었는지, end 서버나 중간 제공자에 연결되었는지 알 수 없다. load-balancing이나 proxy server가 그 예시이며, 이는 Client와 Server간의 소통에 영향을 미치지 않는다. 레이어 구조를 통해 scalability와 reliability를 향상시킬 수 있으며, 서비스라 불리우는 비즈니스 로직과 Client를 분리시킬 수 있어 security를 강화시킬 수 있다.
Code on demand (optional)
Server는 executable 코드의 전송을 통해 Client가 제공받는 서비스의 기능성을 확장시킬 수 있다. 대표적인 예로, Client-side 스크립트인 JavaScript와 컴파일된 Java applet 등이 있다.
Uniform interface
RESTful 시스템 디자인의 핵심으로, 일관적 인터페이스는 아키텍쳐를 디커플링하며 단순화 한다. 이는 아키텍쳐의 구성요소들을 독립적으로 개발, 발전, 유지보수할 수 있게 만들어준다.
RESTful
앞서 소개한 REST의 가이드라인을 따라 구현 또는 정의한 아키텍쳐를 뜻한다. REST는 프로토콜이나 공식 기준이 아님으로 정의된 아키텍쳐는 없지만, REST의 Uniform Interface 제약에 따라 HTTP: JSON, HTML, XML 등의 각종 형식을 암묵적으로 따른다.
REST API, RESTful API
REST의 가이드라인을 준수하는 API(Application Programming Interface)이다. REST 가이드라인의 근간이 되는 Uniform Interface 제약사항을 Web 환경에 적용하기 위해 다음과 같은 4가지 제약사항을 추가하여 URI, HTTP Methods, Media type을 정의한다.
Resource identification in requests: 개별의 자원들은 요청을 통해 식별되고 접근될 수 있다. Web 기반의 RESTful API에서는 URI의 형태로 식별할 수 있다. 대체로 요청한 자원과 실제 응답받은 자원은 형태가 다른데, 예컨데 Client가 응답받는 HTML, XML, JSON 형식의 데이터는 Server의 DB에 내부적으로 저장하고있는 Entity의 형태와 다르다.
Resource manipulation through representations: Client는 자원의 metadata 또는 HTTP Methods와 같은 표현을 통해 자원을 수정하거나 삭제하여 자원의 상태를 바꿀수 있다.
Self-descriptive messages: Request나 Response를 통해 전달되는 메시지는 자신이 어떻게 처리되어야 하는지 충분한 정보를 포함해야 한다. 예로, Content-type 헤더에 Media type을 정의하거나 Link 헤더에 명세를 확인할 수 있는 링크를 넣어야 한다.
Hypermedia as the engine of application state(HATEOAS): Server는 Client에게 현 위치에서 탐색할 수 있는 모든 자원들을 링크의 형태로 제공해야 한다. 예로, 메인 홈페이지에 접속한 Client에게 마이페이지, 메뉴 페이지 등 Client의 현재 위치에서 접근할 수 있는 서브 페이지들의 링크를 제공해야 한다.
아래 두 제약조건을 잘 설명해주신 블로그가 있어 참고하면 좋을것 같다.
