오늘은 블로깅 시간이 있다!
그동안 말로만 들었던 REST API를 배워보고, 그 개념을 정리하려고 한다.
다음에 다시 찾아볼 때를 대비해서 참고 사이트도 함께 정리할 예정 😉
HTTP URI
로 표현 -->HTTP 프로토콜
을 통해 요청과 응답을 정의하는 방식❗️ HTTP 프로토콜을 기반으로 요청과 응답에 따라 리소스를 주고받기 위해서 API는 모두가 잘 알아볼 수 있도록 작성하는 것이 중요!
---> REST는 가이드라인이며, 발표된 후로 관련 개념과 용어가 널리 사용되어 지금은 거의 업계 표준이라 할 정도의 영향력이라고 한다. 다만 가이드라인이기 때문에 지키지않는다고 오류가 생기는 것은 아니다! 일종의 약속인 것이지.
레오나르드 리차드슨은 REST API를 보다 실용적으로 적용하기 위한 4단계 모델(0~3단계)을 만들었다.
로이 필딩은 이 모델의 모든 단계를 충족해야 REST API라고 주장
--> 그러나 실제로 2단계까지만 적용해도 좋은 API 디자인👍이라고 볼 수 있고, 이런 경우를 HTTP API
라고도 부른다.
0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 OK👌🏻
물론 해당 API를 REST API라고 할 수는 없고 0단계는 REST API를 작성하기 위한 기본 단계
라고 보면 된다.
💙 허준이라는 이름의 주치의의 예약 가능한 시간을 확인
💙 어떤 특정 시간에 예약하는 상황
위 예시에서는 HTTP 프로토콜을 사용하고 있다. 이렇듯 단순히 HTTP 프로토콜을 사용하는 것이 REST API의 출발점! 🚩
REST API는 웹에서 사용되는 모든 데이터나 자원(Resource) 을 HTTP URI
로 표현한다.
[1단계의 핵심]
모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다!
💙 0단계에서는 요청에서의 엔드포인트로 모두 /appointment를 사용
💙 하지만 1단계에서는 요청하는 리소스가 무엇인지에 따라 다른 엔드포인트로 구분
[엔드포인트 사용]
예약 가능한 시간 확인 -> 요청
허준이라는 의사의 예약 가능한 시간대 -> 응답으로 받게 되는 자원(리소스)
특정 시간에 예약 -> 요청
❗️ 어떤 리소스를 변화시키는지 혹은 어떤 응답이 제공되는지에 따라 각기 다른 엔드포인트를 사용하기 때문에, 적절한 엔드포인트
를 작성하는 것이 중요
❗️ 엔드포인트 작성 시에는 리소스에 집중해 명사 형태의 단어
로 작성하는 것이 바람직한 방법!
(동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양)
더불어 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야 한다.
💙 김코딩 환자가 9시에 예약하였으나 해당 시간이 마감되어 예약 불가능으로 가정
💙 아래와 같이 리소스 사용에 대한 실패 여부를 포함한 응답을 받아야 한다.
⭐️ CRUD
⭐️에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 둔다.
예약 가능한 시간을 확인
예약 가능한 시간을 조회(READ)
하는 행위를 의미
--> GET
메서드를 사용하여 요청을 보내고, GET 메서드는 body를 가지지 않기 때문에 query parameter
를 사용하여 필요한 리소스를 전달
특정 시간에 예약
해당 특정 시간에 예약을 생성(CREATE)
한다는 것
--> POST
메서드를 사용하여 요청을 보내야 하며, POST 요청에 대한 응답이 어떻게 반환되는지가 중요!
201 Created
로 명확하게 작성해야 한다. [HTTP 메서드 사용 규칙]
GET
: 서버의 데이터를 변화시키지 않는 요청
POST
: 요청마다 새로운 리소스를 생성 (멱등성 x)
PUT
: 요청마다 같은 리소스를 반환 (멱등성 o)
PUT
은 교체, PATCH
는 수정의 용도로 사용
멱등(idempotent) : 매 요청마다 같은 리소스를 반환하는 특징
---> API를 작성할 때, REST 성숙도 모델의 2단계까지 적용하면 대체적으로 잘 작성된 API라고 볼 수 있다.
모범적인 API 디자인조차도 REST 성숙도 모델의 3단계까지 적용한 경우는 드물기 때문에, 3단계까지 무조건적으로 모두 적용해야 하는 것은 아니다! 🙅🏻♀️
HATEOAS(Hypertext As The Engine Of Application State)
라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용
링크 요소
를 삽입하여 작성--> 응답에 들어가게 되는 링크 요소
는 응답을 받고 나서 할 수있는 다양한 액션을 위해 하이퍼미디어 컨트롤을 포함
[3단계의 핵심 포인트]
응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것
💙 허준 의사의 예약 가능 시간을 확인한 후
💙 그 시간대에 예약을 할 수 있는 링크를 삽입
or
💙 특정 시간에 예약을 완료하고 나서 그 예약을 재확인할 수 있도록 링크를 작성
이 API에는 Open
이라는 키워드가 붙어 있다.
누구에게나 열려있는 API이지만 "무제한으로 이용 가능"이라는 의미는 아니다!
API마다 정해진 이용 수칙이 있고, 그 이용 수칙에 따라 제한사항(가격, 정보의 제한 등)이 있다.
[Open API 예시]
API를 이용하기 위해서는 API Key
가 필요
--> API key는 서버의 문을 여는 열쇠 🔑 이다.
서버 입장에서 아무런 조건 없이 익명의 클라이언트에게 데이터를 제공할 의무 x
왜? 서버를 운용하는 데에 비용이 발생하니까!
API Key가 필요한 경우
로그인한 이용자에게 자원에 접근할 수 있는 권한을 API Key
의 형태로 제공
데이터를 요청할 때 API key
를 같이 전달해야 원하는 응답을 받을 수있다.
RESTful API란 무엇인가요? aws
프론트엔드와 백엔드가 소통하는 엔드포인트, RESTful API
그런 REST API로 괜찮은가
구글 REST API 작성 가이드라인
마이크로소프트 REST API 작성 가이드라인