REST API
REST API에서 REST란 “Representational State Transfer”의 약자
REST API
웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고 HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.
REST API 의 목표
간단하고, 일관적이고, 사용이 간편한네트워크 API를 디자인할 수 있도록 하는 데에 있다.
REST 성숙도 모델
로이 필딩이 논문에서 제시한 REST 방법론을 실용적으로 적용시키기 위해서 레오나르드 리차드슨(Leonard Richardson) 고안한 4단계로 이루어진 REST API 모델
REST 성숙도 모델 - 0단계
REST 성숙도 모델에 따르면 0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 된다.
하지만 이 경우 해당 API를 REST API라고 할 수는 없다.
즉, 0단계는 REST API를 작성하기 위한 기본 단계인 셈이다.
다음 표는 김헤어라는 헤어 스타일리스트의 예약 가능 시간을 확인하고 특정 시간에 예약을 하는 상황에 대한 API 예시다.
| 요청 내용 | 요청 | 응답 |
| 예약 가능한 시간 확인 |
POST/appointment HTTP/1.1
[Header 생략]
{
"date": "2022-08-10", "stylist" : "김코딩"
} |
HTTP/1.1 200 OK { "slots"[ "stylist" : "김헤어", "start" : "09:00", "end" :"12:00"} "stylist" : "김헤어", "start" : "14:00", "end" :"16:00"} ] } |
| 특정 시간에 예약 |
POST/appointment HTTP/1.1 [Header 생략] { "stylist" : "김헤어" "start" : "14:00" "end" :"15:00" "reservename" : "김코딩" } |
HTTP/1.1 200 OK [HEADER 생략] |
REST 성숙도 모델 - 1단계
REST 성숙도 모델 - 1단계에서는 개별 리소스(Resource)와의 통신을 준수해야 한다.
REST API는 "웹에서 사용되는 모든 데이터나 자원(Resource)을 HTTP URI로 표현"한다.
REST API 1단계의 핵심: 모든 자원은 개별 리소스에 맞는 엔드포인트(EndPoint)를 사용해야하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야한다.
(0단계에서는 요청에서의 엔드포인트로 모두 /appointment를 사용했다.
하지만 1단계에서는 요청하려는 리소스가 무엇인지에 따라 각기 다른 엔드포인트로 구분하여 사용한다.)
아래의 표는 REST 성숙도 모델 - 1단계를 적용한 예시이다.
| 요청 내용 | 요청 | 응답 |
| 예약 가능한 시간 확인 |
POST /stylists/김헤어 HTTP/1.1 [HEADER 생략] { "date": "2022-08-10" } |
HTTP/1.1 200 OK [Header 생략] { "slots"[ {"id : 123", "doctor" : "허준", "start" : "09:00", "end" :"12:00"} {"id : 124", "doctor" : "허준", "start" : "14:00", "end" :"16:00"} ] } |
| 특정 시간에 예약 |
POST /slots/123 HTTP/1.1 [HEADER 생략] { "reservename" : "김코딩" } |
HTTP/1.1 200 OK [Header 생략] { "appointmentfailure" : { "slots" : ["id" : "123", "doctor" : "허준", ...} "patient" : "김코딩" "reason" : "해당 시간은 이미 예약되어 있습니다." ] } |
위의 예시에서 예약 가능한 시간 확인 이라는 요청의 응답으로 받게 되는 자원(리소스)은 '김헤어라는 스타일리스트의 예약 가능한 시간대' 그래서 요청 시 /stylists/김헤어라는 엔드포인트를 사용한다.
특정 시간에 예약하게 되면 slots라는 리소스의 123이라는 id를 가진 리소스가 변경되기 때문에
하단의 특정 시간에 예약이라는 요청에서는 /slots/123으로 실제 변경되는 리소스를 엔드포인트로 사용한다.
예시와 같이 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용하기 때문에 적절한 엔드포인트를 작성하는 것이 중요하다.
또한 요청에 따른 응답으로 리소스를 전달할 때 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야한다.
예를 들어, 김코딩 손님이 김헤어 스타일리스트에게 9시에 예약을 진행하였으나 해당 시간이 마감되어 예약이 불가능하다고 가정할 때 리소스 사용에 대한 성공 여부를 포함한 응답을 받아야한다.
REST 성숙도 모델 - 2단계
REST 성숙도 모델 2단계에서는 CRUD에 맞게 적절한 HTTP 메서드를 사용한다.
0단계와 1단계 예시에서는 모든 요청을 CRUD(Create, Read, Update, Delete)와 상관없이 POST 메서드를 사용했다.
예약 가능한 시간을 확인한다는 것은 예약 가능한 시간을 조회(READ)하는 행위를 의미 -> 조회(READ)하기 위해서는 GET 메서드를 사용하여 요청한다.
-> GET 메서드는 body를 가지지 않기 때문에 query parameter를 사용하여 필요한 리소스를 전달한다.
특정 시간에 예약한다는 것은 해당 특정 시간에 예약을 생성(CREATE)한다는 것 -> 예약을 생성(CREATE)하기 위해서는 POST 메서드를 사용하여 요청한다.
-> 어떤 응답이 반환되는지가 중요!-> 응답은 새롭게 생성된 리소스를 보내주기 때문에, 응답 코드는 201 Created 로 명확하게 작성! -> 관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할 수 있도록 작성해야 한다.
| 요청내용 | 요청 | 응답 |
| 예약 가능한 시간 확인 |
GET /stylist/김헤어/slots?date=2022.08.10 HTTP/1.1 [Header생략] |
HTTP/1.1 200 OK [Header 생략] { "slots"[ {"id : 123", "stylist" : "김헤어", "start" : "09:00", "end" :"12:00"} {"id : 124", "stylist" : "김헤어", "start" : "14:00", "end" :"16:00"} ] } |
| 특정 시간에 예약 |
POST /slots/123 HTTP/1.1 [HEADER 생략] {"resrvername" : "김코딩"} |
HTTP/1.1 201 created Location: [Header 생략] { "appointment" : { "slot" : {"id" : "123", "stylist" : "김헤어", ...} "reservename" : "김코딩" } } |
★★★
HTTP 메서드를 사용할 때 다음의 규칙에 유의해야한다.
1) GET 메서드는 서버의 데이터를 변화시키지 않는 요청에 사용해야 한다.
2) POST 메서드는 요청마다 새로운 리소스를 생성 & PUT 메서드는 요청마다 같은 리소스를 반환한다.
(멱등성(idempotent)을 가지고 있음) 따라서 생성할 때 PUT 쓰지 말고 반환할 때 POST를 쓰지 말자.
3) PUT 메서드와 PATCH 메서드를 구분하여 사용해야 한다.
-> (PUT 메서드는 전체 교체, PATCH 메서드는 일부 수정)
REST 성숙도 모델 -3단계
HATEOAS(Hypermedia As The Engine Of Application State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용했다.
3단계의 요청은 2단계와 동일하지만 응답에는 리소스의 URI를 포함한 링크 요소를 삽입해야한다. 이 때 응답에 들어가게 되는 링크 요소는 응답을 받은 다음 할 수 있는 다양한 액션들을 위해 많은 하이퍼 미디어 컨트롤을 포함한다.
| 요청내용 | 요청 | 응답 |
| 예약 가능한 시간 확인 |
GET /doctors/허준/slots?date=2022.08.10 HTTP/1.1 [Header 생략] |
HTTP/1.1 200 OK [Header 생략] { "slots"[ {"id : 123", "stylist" : "김헤어", start" : "09:00", "end" :"12:00"} {"id : 124", "stylist" : "김헤어", "start" : "14:00", "end" :"16:00"} ], "links" : { "appointment" : { "href" : http:/ "method" : "POST" } } } |
| 특정 시간에 예약 |
POST /slots/123 HTTP/1.1 [Header 생략] { "reservename" : "김코딩" } |
HTTP/1.1 201 created Location: [Header 생략] { "appointment" : { "slot" : {"id" : "123", "stylist" : "김헤어", ...} "reservename" : "김코딩" } } "links" : { "self" : { "href" : "http://localhost.8000/slots/123" "method" : "GET" } "cancel" : { "href" : {"http://localhost.8000/slots/123" "method" : "DELETE" } } { |
예시) 김헤어라는 스타일리스트의 예약 가능 시간을 확인한 후에는
1. 그 시간대에 예약을 할 수 있는 링크를 삽입하거나,
2.특정 시간에 예약을 완료한 후에 그 예약을 다시 확인할 수 있도록 링크를 작성한다.
이러한 링크들은 조금 더 쉽고, 효율적으로 리소스와 기능에 접근할 수 있게 하는 요소가 될 수 있다.
Open API
글자 그대로 누구에게나 열려있는 API
그러나 "무제한으로 이용할 수 있다"라는 의미는 아니다.
API마다 정해진 이용 수칙이 있고, 그 이용 수칙에 따라 제한사항(가격, 정보의 제한 등)이 있을 수 있다.
API Key
API를 이용하기 위해서는 API Key가 필요하다.
서버를 운용하는 데에 비용이 발생하기 때문에 서버 입장에서 아무런 조건 없이 익명의 클라이언트에게 데이터를 제공할 의무는 없다.
=> API Key가 필요한 경우에는 로그인한 이용자에게 자원에 접근할 수 있는 권한을 API Key의 형태로 제공 & 데이터를 요청할 때 API key를 같이 전달해야 원하는 응답을 얻을 수 있다.
'Understanding Web' 카테고리의 다른 글
| [WEB] OAuth란? (0) | 2023.03.09 |
|---|---|
| SEO(Search Engine Optimization) (0) | 2023.03.01 |
| [WEB] What is CORS?(CORS란 무엇인가) (0) | 2023.02.06 |
