RMM - Richardson Maturity Model (4단계)

moontag·2022년 6월 10일

네트워크

목록 보기

9/18

Richardson Maturity Model

REST 성숙도 모델
레오나르드 리차드슨(Leonard Richardson)은 REST API를 잘 적용하기 위해 총 4단계(0~3단계) 모델을 정의했다.

REST API를 발표한 로이 필딩은 모든 단계를 충족해야 REST API라고 부를 수 있다고 했다. 하지만 3단계까지 지키기 어렵기 때문에 2단계까지만이라도 좋은 API 디자인이라고 볼 수 있고 이를 HTTP API라고 부른다.

HTTP API : 2단계까지 준수
REST API : 모든 단계 준수

REST API 구성

자원(RESOURCE) : URI
행위(Verb) : HTTP Method (GET, POST, PUT, DELETE)
표현(Representations)

URI로 정보의 자원(RESOURCE)을 표현
HTTP Method로 자원(RESOURCE)에 대한 행위(Verb) 표현

0단계 : HTTP 사용

HTTP 프로토콜 사용

단일 URI를 가지며 단일 HTTP 메소드(일반적으로 POST)를 사용
해당 API를 REST API라 부를 순 없다. 이는 REST API 작성의 기본단계다.

1단계 : URI Resource

개별 리소스(Resource) 추가

요청을 단일 서비스 endpoint로 보내는 것이 아니라, 개별 리소스로 통신한다.
예를 들어 /movies 로 모든 요청을 전달하는 것보다, /posts/1 과 같이 posts라는 리소스를 만들어 1번 게시글이라는 리소스를 이해할 수 있도록 URI를 설계한다
많은 URI를 사용하지만 단일 HTTP Verb(일반적으로 POST)만 사용.
이는 시스템에서 사용 가능한 각 리소스에 고유한 URI를 제공한다. 고유한 URI는 하나의 고유한 리소스를 개별적으로 식별하므로 이러한 서비스가 0단계보다 우수하다.
개별 리소스에 맞는 Endpoint를 사용
요청에 맞는 정보를 응답으로 전달해야한다

Endpoint 작성

동사 단어, HTTP 메서드, 어떤 행위에 대한 단어 지양한다

리소스에 집중한 명사 단어가 바람직하다

2단계 : HTTP Verbs

URI Resources + HTTP Method(CRUD에 적합하게 작성)

리소스와 HTTP Method로 요청대상과 목적을 파악할 수 있다.
- 예) GET /posts/1/comments?from=20220424&to=20221027
  : posts(게시글) 중 1번 게시글의 comments(댓글)을 GET(조회)하고 조건으로는 생성일 기준 from, to 기간 안에서 조회한다.
  저 1줄의 요청으로 어떤 리소스로 무슨 행위를 할 것 인지 파악할 수 있다.
- HTTP Method
  GET : 조회. 서버의 데이터를 변화시키지 않는 요청
  POST : 생성. 요청마다 새로운 리소스를 생성해 서버의 상태를 변경하므로 멱등성을 갖지 않음
  PUT : 전체 수정(덮어쓰기). 요청된 리소스로 전부 교체됨, 요청마다 같은 리소스를 반환
  PATCH : 부분 수정. 멱등이거나 멱등이 아니게 설계할 수도 있음
  DELETE : 삭제
  - 멱등(idempotent)하다 : 매 요청마다 같은 리소스를 반환하는 특징
    그렇기 때문에 멱등성을 가지는 PUT과 그렇지 않은 POST는 구분해야 한다.
    PATCH는 멱등이거나 멱등이 아니게 설계할 수도 있다.
  1. PATCH 메서드가 멱등인 경우
    글 title만 변경하는 api의 경우, 중복 요청에도 서버 상태는 동일하므로 멱등성이 있다.
  2. PATCH 메서드가 멱등이 아닌 경우
    1번째요청 {views : 0 + 1} => 1번응답 {views : 1}
    2번째요청 {views : 0 + 1} => 2번응답할 때
    {views : 1}이 아니라 서버에서 {views : 2}로 증가, 변경시켰다면 멱등이 아니다.
    위 글 조회수 증가 api 경우, 여러번 요청을 하게 되면 매번 증가된 다른 결과(조회수)가 나오므로 멱등이 아닌 경우에 해당한다.
    멱등이게 하려면 여러번 요청해도 항상 같은 {views : 1}이 나와야 한다.

Status Code로 서버-클라이언트 간 소통할 수 있다.
추가적으로 위 요청에 대해서 서버는 Status Code로 클라이언트 간 커뮤니케이션이 가능해졌다. 응답코드 200은 작업이 정상적으로 진행된 것이고, 응답코드 400은 잘못된 요청임을 알리는 데 사용된다.
- HTTP Status Code
  200 : OK
  201 : Created, 리소스가 정상적으로 생성
  301 : Moved Permanently, 리소스의 URI가 변경 됨
  400 : Invalid Request, 잘못 된 요청
  401 : UnAuthorized, 인가되지 않은 요청
  404 : Not Found, 리소스를 찾을 수 없음
  500 : Internal Server Error, 서버의 내부 에러

3단계까지 적용한 경우는 드물다. 무조건적으로 준수해야하는 것은 아니며, 2단계까지 적용한 것을 HTTP API라고 부른다.

HTTP API : 2단계까지 준수한 API
REST API : 3단계까지 준수한 API

3단계 : HATEOAS

URI + HTTP Method + HATEOAS

HATEOAS(Hypertext As The Engine Of Application State)
: 애플리케이션의 상태는 Hypertext를 이용해 전이돼야 한다

클라이언트가 요청하고 응답받은 후, 다음 단계로 할 수 있는 작업(전이)을 알려주는 것이다.
서버는 다음 단계 작업을 위한 URI를 포함한 링크요소를 제공한다. 이를 제공하면 클라이언트는 다음 단계에 대한 행위를 클라이언트에서 관여하지 않고 서버에 응답으로서 작업을 정의할 수 있게 된다.

예 ) 1번 게시글의 댓글들을 조회하는 API를 요청 시
=> 응답으로 조회한 결과(댓글 목록) 화면 링크, 댓글 좋아요 API URI를 응답으로 제공하는 것이다.
이렇게 응답에 리소스들로 할 수 있는 행위를 URI로 제공받으면 클라이언트는 그 응답만으로 다음 서버 처리를 할 수 있다.

요청 : 2단계와 동일

응답 : 리소스의 URI를 포함한 링크 요소를 삽입하여 작성

링크 요소
응답을 받은 다음에 하는 다양한 작업들을 위한 링크를 포함한다. 응답 내에 새로운 링크를 넣어서 새로운 기능에 접근할 수 있도록 한다.
예) 의사의 예약 가능 시간 확인 후
=> 해당 시간대 예약할 수 있는 링크 삽입, 예약 확인 링크 삽입

Open API

누구나 사용 가능한 API다. 무제한 이용은 아니고, 이용 수칙과 가격, 정보 제한 등에 따라 제한 사항이 있을 수 있다.
날씨 API로는 대표적으로 Open Weather Map이 있다.
정부에서 제공하는 공공데이터가 있는데 공공데이터 사이트에서 검색하면 관련된 오픈 API를 찾을 수 있다.