REST API ::
Representational State Transfer
웹에서 사용되는 데이터나 자원을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식
원격 데이터를 가져오거나 변경하는 웹 서비스를 설계하는 아키텍처 스타일
REST API = {URI,HTTP,HATEOAS(Hypermedia)}
REST API를 디자인하는 방법
참고
https://nordicapis.com/what-is-the-richardson-maturity-model/
https://devopedia.org/richardson-maturity-model
리차드슨의 REST 성숙도 모델
웹서버를 데이터저장소로 간주하자.
2단계까지만 지켜도 좋은 API라 할 수 있다.
REST Maturity model - Lv.0
0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 된다. 이 경우 REST API라고 할 수는 없고, REST로 가기 위한 기본 단계라고 볼 수 있다.
전체 애플리커에션에 대해 하나의 URI만 노출한다.
모든 작업에 HTTP POST를 사용한다.
POX(Plan Old XML)
REST Maturity model - Lv.1
1단계에서는 개별 리소스와의 통신을 준수해야한다. 즉 리소스에 기반한다는 뜻!
모든 자원은 개별 리소스에 맞는 Endpoint를 사용해야하며 요청하고 받는 자원에 대한 정보를 응답으로 전달해야한다. (리소스 기반 주소 지정)
URI를 여러가지 사용하지만 HTTP POST만 사용한다.
사용한 리소스에 대한 정보 + 리소스 사용에 대한 성공/실패여부 반환해야 한다.
- 엔드포인트 : 같은 URL 내에서도 다른 요청을 하게끔 구별하게 해주는 항목. 리소스에 접근할 수 있도록 하는 URL을 말한다!
- 엔드포인트 작성 시: 동사, HTTP 메서드, 혹은 어떤 행위에 대한 단어 사용은 지양하고, 리소스에 집중해
명사 형태의 단어로 작성한다.
REST Maturity model - Lv.2
CRUD에 맞게 적절한 HTTP메서드를 사용하는 것에 중점을 둔다.
모든 HTTP 메서드 사용. (GET, POST, PUT, DELETE)
전 단계에서 리소스를 사용하게 되었으니 이제 해당 리소스와 상호작용을 한다.
- GET: 서버의 데이터를 변화시키지 않는 요청. 가져오기 작업
- POST: 요청마다 새로운 리소스 생성
- PUT: 요청마다 같은 리소스 반환(멱등성
..?띠용.idempotent), 교체용도. - PATCH: 수정의 용도
멱등성이란? 덮을 멱 같을 등. 연산을 여러번 적용하더라도 결과값이 달라지지 않음
PUT vs PATCH
유저 리소스를 수정하려고 한다. 이때
현재: { id: 1, name: 'pomeranian' } // 모든 내용을 보내야함. 안그러면 해당 요소가 사라지게되는 불상사가 벌어진다. PUT /users/1 { id: 1, name: 'seolgi' } PATCH /users/1 { name: 'seolgi' } //수정할내용만 보내면 됨put : 리소스를 대체한다.
patch: 해당 리소스만을 수정한다.
REST Maturity model - Lv.3
HATEOAS :: Hypertext As Engine Of Application State
기본적으로 리소스 링크와 양식으로 구성된 HyperMedia라고도 한다.
요청은 2단계와 동일하지만 응답에는 리소스의 URI + 링크 요소 삽입해서 작성.
응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 한다.
REST API 정리
정리하자면,
1. URI로 리소스를 표현한다. (행위가 아니라 주체, 대상)
행위를 표현하지 않음, 즉 동사를 쓰지 않는다.
URI는 리소스와 리소스의 계층구조만을 표현한다.
2. 행위는 HTTP Method로 표현한다.
Open API
공공데이터
실습
Open Weather Map
무료로 날씨 API사용. (프리플랜)
데이터 JSON형태로 응답
API Key
로그인한 이용자에게 자원에 접근할 수 있는 권한 제공.
키를 같이 전달해야 요청시 응답을 받을 수 있다.
