한 줄 요약: REST는 이론적이고 이상적인 가이드라인을 가진 아키텍처 스타일이고,
RESTful API는 REST에서 영감을 받아 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.)" --
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가 훨씬 더 사용하기 쉽다.
<끝.>
RESTful API의 일부 특징은 REST와 다른데, 다른 점들은 어떤 것들이 있습니까?
RESTful API는 REST 아키텍처 스타일을 따르지만, REST와는 몇 가지 다른 특징이 있습니다. 다음은
RESTful API와 REST의 차이점입니다.
- Hypermedia 제어: RESTful API에서는 Hypermedia 제어(HATEOAS)를 사용하지 않아도 됩니다. 이는 REST에서 권장되는 방법입니다.
- Statelessness: RESTful API에서는 서버의 상태를 저장하고 있을 수 있습니다. 하지만 REST에서는 서버의 상태를 저장하지 않아야 합니다.
- URI 디자인: RESTful API에서는 URI 디자인에 대한 일관성이 덜 중요합니다. REST에서는 URI 디자인의 일관성이 매우 중요합니다.
- 메시지 형식: RESTful API에서는 JSON 형식을 많이 사용합니다. REST에서는 XML 형식을 많이 사용했지만, 요즘에는 JSON이 더 많이 사용됩니다.
- HTTP 메서드: RESTful API에서는 HTTP 메서드를 사용하지 않는 경우도 있습니다. 예를 들어, RPC(Remote Procedure Call)를 사용하여 API를 작성하는 경우에는 HTTP 메서드를 사용하지 않습니다. 반면, REST에서는 HTTP 메서드를 사용해야 합니다.
- URI 버전 관리: RESTful API에서는 URI 버전 관리를 하지 않아도 됩니다. REST에서는 URI 버전 관리를 해야 합니다.
이러한 차이점들은
RESTful API가 REST와는 다른 특징을 가지고 있다는 것을 보여줍니다. 하지만,
RESTful API는 여전히 REST 아키텍처 스타일을 따르기 때문에, REST와 매우 유사한 방식으로 동작합니다.