REST와 RESTful API의 차이

Edit Diff Refresh Backlink Random Search History Help Setting

한 줄 요약:
REST는 이론적이고 이상적인 가이드라인을 제시하는 아키텍처 스타일이며,
RESTful API는 이러한 REST의 원칙에서 영감을 받아 그 아키텍처 스타일을 따르는 실용적인 웹 API이다.

REST: Representational State Transfer의 약자로, 웹 기반 시스템에서 클라이언트와 서버 간의 통신 방식을 정의한 아키텍처 스타일이다. 자원(resource)을 URI로 식별하고 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 행위를 정의한다.

RESTful API: REST 아키텍처 스타일을 따르는 API를 말한다. 즉, 자원을 URI로 식별하고 HTTP 메서드를 사용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하는 API를 의미한다.

실용적이라는 말은 해석하기 나름이지만, 웹 API는 사용하기 쉬워야 한다는 데에는 다들 동의하는 편이다. 외부 개발자가 보았을 때 이해하기 쉬워야 하고, 일관되어야 하고, 예측 가능하고, REST의 많은 부분을 따라야 한다. REST의 일부 디자인 스타일을 구현하면 이런 종류의 사용 편의성이 생긴다. 사람들이 종종 오해하는 것과는 다르게, REST 제약은 원래 단기 생산성이나 개발자의 사용 편의성과는 정반대로 만들어졌다.

"REST는 수십 년의 시간을 염두에 둔 소프트웨어 설계 방식입니다. 모든 세부 요소는 소프트웨어의 수명을 길게 유지하고, 서로 독립적으로 진화할 수 있도록 하기 위해 존재합니다. 이러한 제약들 가운데 상당수는 단기적인 효율성의 관점에서는 오히려 불리하게 작용합니다. (REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release.)" -- Wikipedia:Roy_Fielding

그렇다면 실용적으로는 REST의 어느 부분을 적용하는 것이 가장 쉬울까? 명사를 이용해서 HTTP 동사가 동작을 취하는 자원(URI)을 일관되게 식별하는 것이 REST의 기본이다. REST에는 성능에 대한 특별한 요구사항은 없지만, 실용적으로는 캐시 자원을 참조하는 기능이 있으면 시스템의 수행과 확장을 돕는다. REST는 추상적인 모델로 여겨지기 때문에 시간에 따라 시스템이 변할 것이라는 사실을 직접적으로 고려하지 않지만, RESTful API는 실용적으로는 API를 변경할 때마다 가능한 이전 시스템과 호환성을 유지하는 방식으로 API 버전을 부여하면 상당한 유연성이 생긴다. 그리고 REST는 클라이언트와 서버를 확실히 분리한다는 설계 자체가 엄청난 이점이 있어 애플리케이션의 개발을 돕는 경향이 있기 때문에 웹 개발에서 영향력이 매우 커졌다. REST의 이런 면을 활용하면 결과적으로 쉽게 이해하고 확장할 수 있는, 공학적으로 우수한 애플리케이션을 만들 수 있다.

RESTful API의 일부 특징은 REST와 상충한다. 가장 주목할 점은, 데이터 전송 방법으로 JSON을 채택한 것이다. JSON은 하이퍼텍스트 링크를 페이로드 할 수 없으므로(최소한 널리 수용된 링크 메커니즘이 없다.) REST의 HATEOAS(Hypermedia As The Engine Of Application State)를 실현할 수 없다. JSON을 사용하면 응답 유형 자체에 정의된 연결을 할 수 없다. 연결할 수 없는 매체를 사용하면, API는 자기 설명적이지 않게 되고 따라서 문서가 필요한 API가 된다. HATEOAS가 이론적으로는 설득력이 있어도, 지속적으로 구현하기에는 어려움이 있는 것이 사실이다. JSON이 웹 API를 위한 사실상 표준 데이터 전송 포맷으로 널리 채택되었기에 더욱 어렵다.

REST 제약 중 하나가 일관된 인터페이스(Uniform Interface)라는 점을 상기해보자. 일관된 인터페이스는 거의 완전히 자기 설명적이다. 이상적으로는 이런 인터페이스로 된 시스템은 시스템의 진입점 이상의 가이드 문서가 필요하지 않다. RESTful API는 모든 자원에 대한 링크를 제공하고, 그 외의 설명을 추가하지 않는다. 현실적으로는, 웹 API의 문서가 잘되어 있으면 RESTful API가 훨씬 더 사용하기 쉽다.

<끝.>

부록: REST와 RESTful API의 주요 차이점

항목 REST RESTful API
Hypermedia 제어 (HATEOAS) HATEOAS를 중요한 제약으로 간주 대부분 구현에서 생략
Stateless 서버는 클라이언트 상태를 저장하지 않아야 함 일부 구현에서 상태를 유지하기도 함
URI 설계 자원 중심의 일관된 URI 설계를 매우 중요하게 봄 실용적으로 설계되어 일관성이 다소 약한 경우도 있음
메시지 형식 초기에는 XML 사용이 많음 (형식 자체는 제한 없음) JSON이 사실상 표준처럼 널리 사용됨
HTTP 메서드 사용 GET, POST, PUT, DELETE 등 HTTP 메서드 의미를 엄격히 사용 RPC 스타일 등으로 의미가 약하게 사용되는 경우도 있음
버전 관리 URI 버전을 선호하지 않는 설계도 존재 /v1, /v2 같은 URI 버전 관리가 흔함
Show Comments