REST API와 성숙도 모델

REST API (Representational State Transfer)

 : 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URL로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의 하는 방식

 

REST API를 디자인하는 방법 

- REST API를 작성할 때 지켜야할 규칙이 있음

- 레오나르드 리차드슨이 4단계 성숙도 모델을 만들었음

0 단계 : HTTP 사용

- 성숙도 모델에 따르면 0단계는 HTTP 프로토콜를 사용하기만 해도 됨

- 0단계는 REST API를 작성하기 위한 기본 단계

 

- [예시] Smith라는 이름의 주치의의 예약 가능한 시간을 확인하고 어떤 특정 시간에 예약하는 상황

요청 내용	요청	응답
예약 가능한 시간	POST /appoinment HTTP/1.1 [헤더 생략] {   "date" : "2022-08-10",   "doctor" : "Smith" }	HTTP/1.1 200 OK [헤더 생략] {   "slots" : [     { "doctor" : "Smith", "start" : " 09:00", , "end" : " 12:00"},     { "doctor" : "Smith", "start" : " 14:00", , "end" : " 16:00"} ] }
특정 시간에 예약	POST /appoinment HTTP/1.1 [헤더 생략] {   "doctor" : "Smith",   "start" : "14:00",   "end" : "15:00",   "patient" : "Dona" }	HTTP/1.1 200 OK [헤더 생략]

 

 

1 단계 : 개별 리소스와의 통신 준수

- 성숙도 모델에 따르면 1단계는 개별 리소스(resource)와의 통신을 준수해야 함

- 앞서 REST API는 웹에서 사용되는 모든 데이터나 자원을 HTTP URI로 표현한다고 했듯이 → 모든 자원은 개별 리소스에 맞는 엔드 포인트(Endpoint)를 사용해야하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다는 것이 핵심

 

[예시] Smith라는 이름의 주치의의 예약 가능한 시간을 확인하고 어떤 특정 시간에 예약하는 상황

- 앞서 0 단계 요처에서는 엔드포인트를 모두 /appoinment로 사용

- but, 1단계에서는 요청하는 리소스가 무엇인지에 따라 다른 엔드포인트로 구분하여 사용

 

- [200 OK - 예시]

요청 내용	요청	응답
예약 가능한 시간	POST /doctor/Smith HTTP/1.1 [헤더 생략] {   "date" : "2022-08-10" }	HTTP/1.1 200 OK [헤더 생략] {   "slots" : [     { "id" : 123, "doctor" : "Smith", "start" : " 09:00", , "end" : " 12:00"},     { "id" : 124, "doctor" : "Smith", "start" : " 14:00", , "end" : " 16:00"} ] }
특정 시간에 예약	POST /slots/123 HTTP/1.1 [헤더 생략] {   "patient" : "Dona" }	HTTP/1.1 200 OK [헤더 생략] {   "appointment" : {     "slot" : { "id" : 123, "doctor" : "Smith", ...},     "patient" : "Dona"   } }

- 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용하기 때문에 적잘한 엔드포인트를 사용하는 것이 중요

- 엔드 포인트 작성 시에는 동사, HTTP method, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스에 집중해 명사 형태의 단어로 작성하는 것이 바람직한 방법

 

 - [409 Conflict]

요청 내용	요청	응답
예약 가능한 시간	POST /doctor/Smith HTTP/1.1 [헤더 생략] {   "date" : "2022-08-10" }	HTTP/1.1 200 OK [헤더 생략] {   "slots" : [     { "id" : 123, "doctor" : "Smith", "start" : " 09:00", , "end" : " 12:00"},     { "id" : 124, "doctor" : "Smith", "start" : " 14:00", , "end" : " 16:00"} ] }
특정 시간에 예약	POST /slots/123 HTTP/1.1 [헤더 생략] {   "patient" : "Dona" }	HTTP/1.1 409 Conflict [헤더 생략] {   "appointmentFailure" : {     "slot" : { "id" : 123, "doctor" : "Smith", ...},     "patient" : "Dona",     "reason" : "해당 시간은 이미 예약되어 있습니다"   } }

- 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공 /  실패 여부를 반환해야 함

 

 

2 단계 : HTTP 메소드 원칙 준수

- CRUD에 맞게 적절한 HTTP 메소드를 사용하는것에 중점을 둠

 

[예시] Smith라는 이름의 주치의의 예약 가능한 시간을 확인하고 어떤 특정 시간에 예약하는 상황

- 예약 가능한 시간을 확인한다는 것은 예약 가능한 시간을 조회(READ)하는 행위이고, 특정 시간에 예약한다는 것은 해당 특정 시간에 예약을 생성(CREATE)한다는 것임

- 그렇기 때문에 조회(READ)하기 위해서서는 GET 메서드를 사용하여 요청을 보내고, 이때 GET 메서드는 body를 가지지 않기 때문에 query parameter를 사용하여 필요한 리소스 전달 

- 또한 예약을 생성하기 위해서는 POST 메소드를 사용하여 요청을 보내여 함

→ 이 경우 응답은 새롭게 생성된 리소스를 보내주기 때문에 응답 코드는 201 Created로 명확하게 작성해야 하며 관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할수 있도록 하면 성숙도 모델 2단계를 충족 시킴

요청 내용	요청	응답
예약 가능한 시간	GET /doctor/Smith/slots?date=2022-08-10 HTTP/1.1 [헤더 생략]	HTTP/1.1 200 OK [헤더 생략] {   "slots" : [     { "id" : 123, "doctor" : "Smith", ... },     { "id" : 124, "doctor" : "Smith",  ... }    ] }
특정 시간에 예약	POST /slots/123 HTTP/1.1 [헤더 생략] {   "patient" : "Dona" }	HTTP/1.1 201 Created Location : slots/123/appointment [헤더 생략] {   "appointmentFailure" : {     "slot" : { "id" : 123, "doctor" : "Smith", ...},     "patient" : "Dona",   } }

 

HTTP 메서드를 사용할 때 규칙

- GET 메서드 같은 경우는 서버의 데이터를 변화시키지 않는 요청에 사용해야 함

-  POST 메서드는 요청마다 새로운 리소스를 생성하고 PUT 메서드는 요청마다 같은 리소스를 반환함.  / 멱등성을 가지는 메서드 PUT과 그렇지 않은 메서드 POST는 구분해서 사용해야 함

- PUT 메서드와 PATCH 메서드도 구분해서 사용해야 함 / PUT은 교체, PATCH는 수정의 용도로 사용

 

* 멱등성(idempotent) : 연산을 여러번 하더라도 결과가 바뀌지 않는 성질

 

 

3 단계 : HATEOAS 원칙 준수

- HATEOAS (Hypermedia As The Engine Of Application State)의 약어로 하이퍼미디어 컨트롤을 적용

- 응답에는 리소스틔 URI를 포함한 링크 요소를 삽입하여 작성해야 함

 

- 이때 응답에 들어가게 되는 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함하고 있음

 

 [예시] Smith라는 이름의 주치의의 예약 가능한 시간을 확인하고 어떤 특정 시간에 예약하는 상황

요청 내용	요청	응답
예약 가능한 시간	POST /doctor/Smith/slots?date=2022-08-10 HTTP/1.1 [헤더 생략]	HTTP/1.1 200 OK [헤더 생략] {   "slots" : [     { "id" : 123, "doctor" : "Smith", ... },     { "id" : 124, "doctor" : "Smith",  ... }    ],   "links" : {       "appointment" : {          "href" : "http://..생략..:8800/slots/123",          "method" : "POST",     }   } }
특정 시간에 예약	POST /slots/123 HTTP/1.1 [헤더 생략] {   "patient" : "Dona" }	HTTP/1.1 201 Created Location : slots/123/appointment [헤더 생략] {   "appointmentFailure" : {     "slot" : { "id" : 123, "doctor" : "Smith", ...},     "patient" : "Dona",   },   "links" : {       "selff" : {          "href" : "http://..생략..:8800/slots/123",          "method" : "GET",     },   "cancel" : {       "appointment" : {          "href" : "http://..생략..:8800/slots/123/cancel",          "method" : "DELETE",     }   } }

- 예를 들어 위와 같이 스미스라는 의사의 예약 가능 시간을 확인 한 후에느 그 시간대 예약할 수 있는 링크를 삽입하거나, 특정 시간에 예약을 완료하고 나서는 그 예약을 다시 확인 할 수 있도록 링크를 작성해 넣을 수 도 있음

- 이렇게 응답 내에서 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 3단계의 핵심 포인트임