위 그림 은 RMM 모델 을 얘기 하 는데 , Leonard Richardson 가 정의 한 REST 방식 의 주요 요소 들 을 3 개 의 단계 로 나눈 모델 을 의미 합니다 . REST 의 영광 ( ? ) 을 얻 기 까지 의 레벨 을 총 0 ~ 3 단계 로 표현 했 는데요 . 
 웹 의 기본 메커니즘 을 전혀 사용 하 지 않 은 단계 로 , HTTP Body 로 데이터 통신 을 하 고 있 긴 하 지만 POX ( Plain Old XML ) 로 요청 과 응답 을 주고받 는 RPC ( Remote Procedure Call ) 스타일 의 시스템 입니다 . HTTP Method 는 POST 만 을 사용 하 며 , 서버 로 요청 하 는 서비스 는 그 자체 로 하나 의 endpoint 를 가지 게 됩니다 . 
 쉽 게 예 를 들 자면 , API 요청 도메인 이 있 고 게시판 기능 을 하 는 서비스 를 만들 었 다고 한다면 , POST / postService ( 게시판 서비스 ) 와 같이 하나 의 endpoint 를 가지 게 되 고 이 endpoint 로 의 요청 Body 의 addPost , getPost 등 필요 로 하 는 내용 을 작성 하 여 요청 을 전달 하 게 됩니다 . 처음 에 언급 했 듯이 HTTP 가 제공 하 는 수많 은 기능 들 을 모두 무시 한 채 데이터 를 통신 하 는 용도 의 모델 입니다 . 
 RMM Level 1 에서 는 Resources ( 이하 리소스 ) 를 도입 합니다 . URI 설계 시 리소스 라는 개념 을 도입 하 여 요청 을 단일 서비스 endpoint 로 보내 는 것 이 아니 라 , 각각 의 리소스 와 통신 하 게 됩니다 . 
 예 를 들 어 , 기존 / postService 로 모든 요청 을 전달 한 것 에 비해서 , 이제 / posts / 1 과 같이 posts 라는 리소스 를 만들 어 1 번 게시 글 이 라는 리소스 를 이해 할 수 있 도록 URI 를 설계 하 게 됩니다 . 이렇게 다양 한 URI 를 사용 하 게 되 었 지만 아직 HTTP Method 는 POST 하나 만 사용 하 고 있 는 상태 입니다 . 
 Level 2 에서 드디어 Level 1 의 URI Resources 와 HTTP Method 를 조합 하 여 사용 함 으로서 동일 리소스 에 대해서 HTTP Method 로 행위 가 결정 되 었 습니다 . 추가 적 으로 HTTP Status Code 로 응답 에 대한 결과 처리 또한 가능 해졌 습니다 . 현재 로서 가장 많 은 RESTful API 가 이 단계 를 제공 하 고 있 습니다 . 
 저 한 줄 의 요청 정보 를 가지 고 이제 우리 는 어떤 리소스 로 어떤 행위 를 할 것 인지 서버 로 요청 할 수 있 게 되 었 습니다 . 
 추가 적 으로 HTTP Status Code 를 언급 했 는데 , 위 요청 에 대해서 서버 는 응답 전문 이외 로 Status Code 로 클라이언트 간 커뮤니케이션 이 가능 해졌 습니다 . 
 HTTP Method 의 종류 ( 대표 적 인 종류 ) 
 GET : 정보 를 요청 하 기 위해 사용 
 POST : 정보 를 입력 하 기 위해 사용 
 PUT : 정보 를 업데이트 하 기 위해 사용 
 DELETE : 정보 를 삭제 하 기 위해 사용 
 OPTION , HEAD , PATCH 등등 
 HTTP Status Code ( 대표 적 인 사용 코드 ) 
 201 : Created , 리소스 가 정상 적 으로 생성 
 301 : Moved Permanently , 리소스 의 URI 가 변경 됨 
 400 : Invalid Request , 잘 못 된 요청 
 401 : UnAuthorized , 인가 되 지 않 은 요청 
 404 : Not Found , 리소스 를 찾 을 수 없 음 
 500 : Internal Server Error , 서버 의 내부 에러 
 마지막 Level 3 는 HATEOAS 라는 것 의 도입 입니다 . 
 HATEOAS 는 ( Hypertext As The Engine Of Application State ) 의 약어 로 , 한마디 로 정리 하 면 , 특정 API 를 요청 한 뒤 클라이언트 입장 에서 이 응답 을 받 은 다음 단계 로 할 수 있 는 작업 ( 전이 ) 을 알려 주 는 것 이 며 , 다음 단계 작업 을 위한 리소스 의 URI 를 서버 에서 제공 하 는 것 입니다 . 이 단계 를 적용 하 면 클라이언트 는 다음 단계 에 대한 행위 를 클라이언트 에서 관여 하 지 않 고 서버 에 응답 으로서 행위 를 정의 할 수 있 게 됩니다 . 
 예 를 들 어 , 위 의 예시 처럼 1 번 게시 글 에 작성 된 댓글 들 을 조회 하 는 API 를 요청 했 다고 하 면 , 그 응답 으로 
 조회 한 결과 ( 댓글 목록 ) 들 을 볼 수 있 는 화면 의 링크 나 그 댓글 에 좋 아요 를 할 수 있 는 API URI 를 응답 으로 제공 하 는 것 입니다 . 이렇게 응답 에 리소스 들 로 할 수 있 는 행위 를 URI 로 제공 받 는 다면 클라이언트 는 그 응답 만 으로 다음 서버 처리 가 가능 하 게 됩니다 . 
 위 에서 Level 0 을 제외 한 Level 1 , 2 , 3 에서 의 특징 인 Resources , Verbs ( HTTP Method ) , HATEOAS 를 가지 고 API 를 설계 한다면 RESTful 한 API 를 설계 할 수 있 을 것 입니다 . 사실 말 하 자면 , 저희 가 개발 하 고 있 는 API 도 아직 은 Level 2 에 머무르 고 있 습니다 . 하 지만 RMM 의 REST 의 영광 을 향해 개선 을 거듭 하 려고 합니다 . 이 포스팅 을 통해서 RESTful 을 바라보 는 개발 자분 들 역시 REST 의 영광 을 얻 기 를 바라 면서 포스팅 마치 겠 습니다 . 
 [ API ] [ HTTP ] [ REST ]