Restful

요즘 대부분의 프로젝트에서 REST API는 많이 사용된다. 대외활동 프로젝트를 진행하면서 스프링 MVC 기반의 REST API를 설계하고 개발해보았다. 하지만 이 API가 진짜 RESTful하다고 볼 수 있을까?
이번 포스팅에서는 그런 rest api로 괜찮은가 라는 영상을 보고 RESTful 제약 조건에 대해서 정리 하고자 한다.

REST API의 탄생

REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표한다.

REST 구성

쉽게 말해 REST API는 다음의 구성으로 이루어져 있다.

• 자원(RESOURCE)

  • 모든 자원에는 고유한 ID가 존재하게 되고, 이 자원은 Server에 존재
  • 자원을 구별하는 ID는 HTTP URL로 구분하게 된다
  • 클라이언트는 URL을 이용하여 자원을 지정하고 해당 자원에 대한 조작을 서버에 요청

• 행위(Verb)

  • 클라이언트는 HTTP 메소드(POST, GET, DELETE, PUT)을 이용하여 지정한 자원에 대한 조작을 요청한다.

• 표현(Representations)

  • 클라이언트가 서버에 자원에 대한 조작을 요청하면 서버는 이에 대한 적절한 응답을 보낸다.

RESTful 제약 조건

• 클라이언트 - 서버(client-server)

  : 이 제약 조건의 기본 원칙은 관심사의 명확한 분리. 관심사의 명확한 분리가 선행되면 서버의 구성요소가 단순화되고 확장성이 향상되어 여러 플랫폼을 지원할 수 있다. 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어들게 됨.

• 무상태성(stateless)

  : 서버에 클라이언트의 상태 정보를 저장하지 않음. 서버는 들어오는 요청만 단순히 처리하면 된다. 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해짐.

• 캐시 가능(cacheable)

  : 클라이언트의 응답을 캐시할 수 있어야 한다. HTTP의 장점을 그대로 계승한 아키텍처가 REST 따라서 HTTP의 캐시 기능도 적용할 수 있어야 함.

• 계층화 시스템

  : 서버는 중개 서버(게이트웨이, 프록시)나 로드 밸런싱, 공유 캐시 등의 기능을 사용하여 확장성 있는 시스템을 구성할 수 있음

• 코드 온 디맨드(code on demand) → 선택 제약조건

  : 클라이언트는 서버에서 자바 애플릿, 자바스크립트 실행 코드를 전송받아 기능을 일시적으로 확장할 수 있음

• 인터페이스 일관성(uniform interface)

  : URI로 지정된 리소스에 균일하고 통일된 인터페이스를 제공한다. 아키텍처를 단순하게 분리하여 독립적으로 만들 수 있음.

  아래 세부 원칙을 갖고 있음

  1. 자원 식별

     → 웹 기반의 REST에서 리소스 접근은 주로 URI을 사용

  2. 메시지를 통한 리소스 조작

     → 클라이언트가 특정 메시지나 메타데이터를 가지고 있으면 자원을 수정, 삭제하는 충분한 정보를 갖고 있는 것. ex) content-type : application/json

  3. 자기 서술적 메시지(self-descriptive message)

     → 각 메시지는 자신을 어떻게 처리해야 하는지 충분한 정보를 포함해야함. HTTP 메소드와 Header을 활용

  4. 애플리케이션 상태에 대한 엔진으로서의 하이퍼미디어(HATEOAS)

     → 클라이언트에 응답할 때 단순히 결과 데이터만 제공해주기보다는 URI를 함께 제공해야 한다는 원칙

이러한 제약 조건들을 모두 제대로 지키면서 REST 아키텍처를 만드는 것을 RESTful이라고 할 수 있다.

정리

• 오늘날 대부분의 REST API는 사실 REST를 따르지 않고 있다.

• REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.

• REST는 긴 시간에 걸쳐(수십년)진화하는 웹 애플리케이션을 위한 것이다.

• REST를 따를 것인지 API를 설계하는 이들이 스스로 판단하여 결정해야한다.

• REST를 따르겠다면, Self-dscriptive와 HATEOAS를 만족시켜야 한다.

  • Self-descriptive는 custom media type이나 profile link relation등으로 만족시킬 수 있다.
  • HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.

• REST를 따르지 않겠다면, REST를 만족하지 않는 REST API를 뭐라고 부를지 결정해야 할 것이다.

  • HTTP API라고 부를 수도 있고
  • 그냥 이대로 REST API라고 부를 수도 있다(로이필딩이라는 분께서 싫어합니다)