REST

REST는 설계적 제약 조건으로 API 스스로에 대한 설명이 가능하여 수 많은 API 소비자에게 채택될 수 있도록 정의된 API 아키텍처 스타일이다.

오늘날 가장 대중적인 REST API 아키텍처 스타일은 2000년 Roy Fielding의 박사 학위 논문에 처음 소개되었다. REST API는 서버 측에서 JSON 및 XML과 같은 간단한 형식의 데이터로 표현 가능하게 한다.

REST 동작 방식

REST는 SOAP만큼 엄격하게 정의되어 있지 않다. RESTful한 아키텍처는 6개의 설계 제약 조건을 준수해야 한다.

• 일관성 있는 인터페이스 : 장비 또는 애플리케이션 타입과 무관하게 목표 서버와 통신하도록 일관성 있는 통신 방법을 허용한다.
• 무상태 : 요청 자체가 요청을 처리하는 데 필요한 상태이고 서버와 세션에 대한 내용을 저장하지 않는다.
• 캐싱 : 자주 필요한 정보를 캐싱하여 통신을 절약한다.
• 클라이언트 - 서버 아키텍처 : 어느 측에서든 독립적으로 발전 가능하다.
• 애플리케이션의 계층화된 시스템
• 서버가 클라이언트에서 실행 가능한 코드를 제공 할 수 있다.

사실 REST로 구현한 서비스의 핵심은 HATEOAS(Hypertext As The Engine of Application State)라 지칭하는 하이퍼미디어를 사용하는 데 있다. 기본적으로 REST API는 모든 응답마다 API 사용 방법에 대한 모든 정보를 묶어 놓은 메타데이터가 담겨 있다. 이 메타데이터를 통해 클라이언트와 서버를 분리 할 수 있다. 결과적으로 API 공급자와 API 소비자 모두 통신을 방해받지 않고 독립적으로 발전할 수 있다.

REST의 장점

1. 클라이언트-서버 분리

• 클라리런트와 서버가 완전히 분리되어있기 때문에 뛰어난 추상화를 제공한다. 그렇기 때문에 세부 속성을 캡슐화하여 내부 속성을 식별하고 유지하는데 용이하다. 이러한 특성은 안정화된 시스템을 유지하면서 REST API를 발전시킬 수 있는 유연성을 제공한다.

2. 캐시 지원

• REST는 HTTP 레벨의 데이터 캐싱이 가능한 유일한 아키텍처이다. 추가적인 캐싱 모듈 없이도 캐싱을 구현할 수 있다.

3. 다양한 형식 지원

• 데이터 저장과 교환을 위하 다양한 형식을 지원한다. (JSON, CML, MultiPart)

REST의 단점

1. 표준적인 형식이 없음

• REST API를 구축하는 방법의 정답은 없다. 리소스를 모델링을 어떻게 할지, 모델링에 어떤 리소스를 사용할지는 상황에 따라 달라진다. 이에 대한 결정을 온전히 객발자에게 맡기기 때문에, 자유도는 높지만 설계에 어려움을 줄 수도 있다.

2. 페이로드가 많음

• REST는 클라이언트가 응답을 통해 애플리케이션 상태를 이해하는데 필요한 수많은 메타데이터를 응답에 포함한다. 이로 인해 REST API는 큰 대역폭을 요구한다. (하지만 대규모 네트워크 파이프에서 이것이 큰 문제가 되지는 않는다)

REST 사용 예시

관리를 위한 API 구현

시스템의 구성 요소 관리를 중심으로 다수의 소비자를 대상으로 하는 API가 가장 일반적인 REST API 사용 예시이다. REST는 API의 강력한 검색 성능, 체계화된 문서를 제공하는데 도움이 되며 객체 모델에도 부합한다.

간단한 리소스 기반 앱

REST는 쿼리의 유연성이 불필요한 리소스 기반의 앱을 연결하는데 유용하다.