REST API 에서 REST 는 Representational State Transfer 의 약자로, 로이 필딩의 박사학위 논문에서 웹(http)의 장점을 최대한 활용할 수 있는 아키텍처로써 처음 소개됐다. 가장 핵심은 리소스 식별이다.
REST API 는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI 로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.
클라이언트와 서버 사이에도 데이터와 리소스를 요청하고 요청에 따른 응답을 전달하기 위한 메뉴판이 필요하다. 이 메뉴판을 보고 클라이언트는 식당에서 식사를 주문하듯 서버에 요청하고, 이에 대한 응답을 메뉴판에 있는 사진이나 음식에 대한 설명처럼 다시 서버에서 클라이언트로 전송하게 된다.
좋은 REST API를 디자인하는 방법
- REST 성숙도 모델은 총 4단계(0~3단계)로 나누어진다.
로이 필딩은 이 모델의 모든 단계를 충족해야 REST API라고 부를 수 있다고 주장했다. 하지만 실제로 3단계까지 지키기는 어렵기 때문에 2단계까지만 적용해도 좋은 API 디자인이라고 볼 수 있고, 이런 경우 HTTP API 라고도 부른다.
REST 성숙도 모델 - 0단계
- HTTP 사용
0단계에서는 단순히 HTTP 프로토콜 을 사용하기만 해도 된다. 물론 이 경우, 해당 API를 REST API 라고 할 수는 없으며, 0단계는 좋은 REST API를 작성하기 위한 기본 단계다.
REST 성숙도 모델 - 1단계
- 개별 리소스와의 통신 준수
REST API 는 웹에서 사용되는 모든 데이터나 자원(Resource)을 HTTP URI로 표현한다. 그래서 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint) 를 사용해야 한다는 것과 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다는 것이 1단계에서 의미하는 바다.
어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용하기 때문에, 적절한 엔드포인트를 작성하는 것이 중요하다.
엔드포인트 작성 시에는 동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스에 집중해 명사 형태의 단어로 작성하는 것이 바람직한 방법이다.
요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야 한다.
예를 들어 만약 김코딩 환자가 허준 의사에게 9시에 예약을 진행하였으나, 해당 시간이 마감되어 예약이 불가능하다고 가정할 때, 아래와 같이 리소스 사용에 대한 실패 여부를 포함한 응답을 받아야 한다.
REST 성숙도 모델 - 2단계
- HTTP 메서드 원칙 준수
GET 메서드 같은 경우는 서버의 데이터를 변화시키지 않는 요청에 사용해야 한다.
POST 는 요청마다 새로운 리소스를 생성하고 PUT 은 요청마다 같은 리소스를 반환한다. 이렇게 매 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)하다고 한다. 그렇기 때문에 멱등성을 가지는 PUT 과 그렇지 않은 POST 는 구분하여 사용해야 한다.
PUT 과 PATCH 도 구분하여 사용해야 한다. PUT 은 교체 , PATCH 는 수정 의 용도로 사용한다.
API를 작성할 때, REST 성숙도 모델의 2단계까지 적용을 하면 대체적으로 잘 작성된 API라고 여긴다.
Reference
REST 성숙도 모델 - 3단계
- HATEOAS(Hypertext As The Engine Of Application State) 원칙 준수
3단계의 요청은 2단계와 동일하지만, 응답에는 리소스의 URI를 포함한 링크 요소를 삽입하여 작성한다는 것이 다르다.
이때 응답에 들어가게 되는 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함하고 있다.
이렇게 응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 3단계의 중요 포인트다.
Reference
