REST API, RMM 성숙도 모델

김민아·2022년 8월 5일

REST API란

REST는 REpresentational State Transfer의 약자이다.

2000년에 Roy Fielding은 웹 서비스를 디자인하는 아키텍처 접근 방식으로 REST를 제안했다. REST API는 웹에서 사용되는 데이터나 자원을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청(Request)과 응답(Response)을 정의하는 방식을 말한다.

RESTful API의 기본 디자인 원칙 👀

REST API는 리소스를 중심으로 디자인되며, 클라이언트에서 엑세스할 수 있는 모든 종류의 개체, 데이터 또는 서비스가 리소스에 포함된다.
리소스마다 고유한 식별을 가능케하는 URI인 식별자가 있다.
클라이언트는 리소스와 표현을 교환하며 서비스와 상호작용한다. 많은 Web API가 교환 형식으로 JSON을 사용한다.
REST API는 균일한 인터페이스로 서비스 구현을 분리한다. 가장 일반적인 작업은 GET, POST, PUT, PATCH, DELETE이다.
REST API는 상태 비저장 요청 모델을 사용한다. HTTP 요청은 독립적이어야 하고 임의 순서로 발행할 수 있으므로, 요청 사이에 일시적인 상태 정보를 유지할 수 없다. 정보는 리소스 자체에만 저장되며 각 요청은 자동 작업이어야 한다. 이러한 제약 조건이 있기 때문에 웹 서비스의 확장성이 우수하다.
REST API는 표현에 포함된 하이퍼미디어 링크에 따라 구동된다. 리소스에 고객을 가져오거나 업데이트하는 링크를 포함한다.

REST 성숙도 모델 (RMM, Richardson Maturity Model)

2008년에 Leonard Richardson은 WEB API에 대해 4단계 성숙도 모델을 제안했다. ~~REST의 영광이 … 어쩐지 천국으로 가는 계단같다~~ 🙀

0단계 - HTTP

HTTP 프로토콜을 단순히 원격 통신을 위한 전송 시스템으로 사용한다. POX(Plain Old XML)을 주고 받는 기본 단계이다.

1단계 - 리소스 Resources

리소스를 도입한다. 개별 리소스에 대한 별도의 HTTP URI로 표현해야 하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다.

리소스에 집중된 명사 형태로 작성한다. /doctor/1
응답으로 리소스를 전달할 때, 리소스 사용에 대한 성공/실패 여부도 반환해야 한다.

2단계 - HTTP 메소드 (Verbs)

HTTP 메서드를 사용하여 리소스에 대한 작업(CRUD, Create, Read, Update, Delete)을 정의한다. 앞서 0, 1단계에서 CRUD에 관계없이 POST를 사용한 것과 비교된다.

GET 메서드는 body를 가지지 않기 때문에 query parameter ?를 사용하여 필요한 리소스를 전달한다.
생성하기 위한 POST 메서드는 응답이 어떻게 반환되는지 중요하다. 응답코드는 201 Created로 명확하게 작성해야 하며, 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할 수 있어야 한다.
GET 메서드는 서버의 데이터를 변화시키지 않는 요청에 사용한다.

2단계에서 GET의 사용은 중요하다. HTTP는 GET을 어떤 순서로든 호출할 수 있고, 상태를 변화시키지 않고, 매번 같은 결과를 얻는 안전한 오퍼레이션으로 정의하기 때문에 캐싱을 할 수 있게 한다. HTTP의 규칙을 준수하면 이런 기능의 장점이 있다.

POST 메서드는 새로운 리소스를 생성하고, PUT 메서드는 요청마다 같은 리소스를 반환한다. (멱등성 idempotent를 가지는 메서드 PUT과 아닌 POST를 구분해야 한다)
PUT 메서드는 교체, PATCH 메서드는 수정의 용도로 사용한다.

잠깐! 여기까지 적용했다면 일반적으로 잘 작성된 API라고 한다. ~~3단계는 정말 Glory한 영역~~ 😅
Fielding의 정의에 따르면 진정한 RESTful API는 3단계에 해당하며 그 전까지는 HTTP API라고 불러야 한단다. 일반적으로 게시된 많은 Web API는 2단계의 어딘가에 해당한다.

3단계 - 하이퍼미디어

하이퍼미디어(HATEOAS)를 사용한다. (Hypertext As The Engine Of Application State 의 약자. ~~헤이트오아스? 끔찍한 약자다.~~) 요청은 2단계와 동일하다. 하이퍼 미디어 컨트롤의 요점은 ‘다음에 무엇을 할 수 있는지’와 ‘어떻게 할지’를 응답에서 리소스의 URI로 알려주는 것이다.

RMM이 가지는 의미는

REST의 요소가 무엇인지 알 수 있는 좋은 방법이지만, REST 자체의 레벨 정의가 아님을 강조한다. 단지 RMM의 유용한 점은 RESTful이 내포하고 있는 기본적인 생각들을 이해하기 위해 점진적인 방법을 제공한다는 것이다. 이를테면,

1단계는 큰 서비스의 엔드포인트를 복수개의 리소스로 나누는 분할과 정복으로 접근할 수 있다.
2단계는 불필요한 다양성을 제거하고 동일한 방식으로 유사한 환경을 처리할 수 있도록 메서드의 집합을 도입할 수 있다.
3단계는 프로토콜을 문서화할 수 있는 방법을 제공함으로써 발견 가능성(discoverability)을 도입할 수 있다.

파면 팔수록 말이 정말 어렵게 느껴진다. 그리고 필딩 박사님 기준이 ~~너무 깐깐~~ 엄격하신 것 같다. HTTP 메서드는 총 8개가 있는데, 이번에 나온 CRUD는 실습을 해보아도 좋겠다. 그리고 이번에 등장한 ~~난생 처음 들어본~~ 멱등성에 관한 개념도 같이 정리해보면 좋을 것 같다. ::TODO::