SEB_19_REST_API

[Keyword]

REST API

REST 성숙도 모델

Open API

API Key

---

1. REST API

REST API = Representational State Transfer API

웹에서 사용되는 데이터나 리소스를 HTTP URI로 표현하고 HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식

 

API는 메뉴판이다 클라이언트는 메뉴판을 보고 요청을 하며, 서버측은 메뉴판에 있는 메뉴가 정상적으로 요청이 됐다면 데이터베이스라는 재료로 메뉴를 만들어 클라이언트 쪽으로 응답해준다.

 

그런데 메뉴판이 너무 다양하다 가게별로 읽는법도 매우 다르다 간혹 어떻게 읽어야 되는지 모르겠는 메뉴판도 있다 그렇다고 메뉴판을 읽을 수 있는 한 가게만 가거나 이상한 메뉴를 주문하고 싶지 않다!!

그렇다면 처음부터 메뉴판을 정해진 형식에 따라 잘 만드는 게 어떨까?? 그럼 모두가 편할텐데라는 생각에서 나온 게 REST API다

이 REST API라는 이론을 실용적으로 적용하기 위해 성숙도 모델을 만들었는데 이를 RMM라고 한다

 

3단계	HATEOAS 준수
2단계	HTTP 메소드 원칙 준수
1단계	개별 리소스와의 통신 준수
0단계	HTTP사용

 

2. REST 성숙도 모델

위 표와 같이 REST 성숙도 모델은 4가지의 단계가 있는데 현실적으로 2단계까지만 적용해도 매우 잘 만든 API이다. 

단계별로 설명하자면 

 

0단계

HTTP 프로토콜을 사용하기만 하는 것 > 이 단계만 가지고 REST API라고 할 수 없다

 

1단계

개별 리소스와의 통신을 준수

웹에서 사용되는 모든 데이터나 자원을 HTTP URI로 표현

 

➡️ 모든 자원을 개별 리소스에 맞는 엔드포인트를 사용해야하며, 요청하고 받는 자원에  대한 정보를 응답으로 전달해야 한다는 것이 핵심

Endpoint를 쓰는 방법

👍 리소스를 잘 표현하는 명사 형태의 단어로 작성 

👎 동사, HTTP 메서드, 어떤 행위에 대한 단어는 지양

 

➡️ 요청에 따른 응답으로 리소스 전달 시에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부 반환

 

2단계

CRUD에 맞는 적절한 HTTP 메서드를 사용하는게 핵심

 

ex)

GET 메서드는 body를 가지지 않으므로 query parameter 사용 필요한 리소스 전달

CREATE를 위해 POST 메서드 사용 > 응답의 반환이 어떤지도 응답 코드 201 Created와 같이 명확하게 작성

+ 관련 리소스를 클라이언트가 Location헤더에 작성된 URI를 통해 확인할 수 있으면 완벽하게 2단계까지 충족시킬 수 있다

 

➡️ 2단계에서는 HTTP 메서드를 적절하게 사용하는게 핵심이니만큼 HTTP메서드 규칙을 몇가지 알아보자

 

요청	적절한 메소드
조회(Read)	GET
추가(Create)	POST
갱신(Update)	PUT or PATCH
삭제(Delete)	DELETE

1) GET 메서드는 서버의 데이터를 변화시키지 않는 요청에만 사용한다 말 그대로 읽기 전용

2) POST vs PUT

    POST 메소드는 요청마다 새로운 리소스를 반환

    PUT 메소드는 요청마다 같은 리소스를 반환 이렇게 매 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)이라고 부른다

    멱등? f(f(x)) = f(x)

    멱등성을 가지는 메소드

    GET, PUT, DELETE

    (PATCH)> PATCH는 사용방법에 따라 멱등성이 있기도 없기도 한다

3) PUT vs PATCH

     PUT 메서드는 전체 교체

     PATCH 메소드는 수정

 

요청

GET/users/1 HTTP 1.1

응답

HTTP/1.1 200 OK
[헤더 생략]
{
 "id" : 1
 "name" : "Choi"
 }

3단계

HATEOAS(Hypertext As The Engine Of Application State)

요청 = 2단계와 동일

응답 = 리소스의 URI를 포함한 링크 요소를 삽입하여 작성 

➡️ 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 핵심

 

3. Open API

Open API 

누구에게나 열려있는 API이지만 무제한으로 이용할 수 있는 것은 아니다 API마다 정해진 이용 수칙이 있고, 이용수칙에 따라 제한사항이 있을 수 있다

 

대표 페이지

네이버 개발자 센터

NAVER Developers

open weather map

공공데이터 포털

공공데이터 포털

 

4. API Key

API를 이용하기 위해 API Key를 사용 

API Key가 필요한 경우 로그인한 이용자에게 자원 접근 권한을 API Key의 형태로 제공하고 데이터 요청 시 API Key를 같이 전달해야 응답을 준다.

왜 API Key가 필요하나요?

만약 우리가 헬스장을 세워서 사장이 된다고 생각해보자 일단 헬스장 부지 찾고, 기구 비용, 리모델링, 어찌저찌 헬스장 개업했다.

근데 헬스장 잘 되려면 새로운 기구도 업데이트해야하고 청소도 해야 하고 운동하는데 기온 중요하니까 에어컨, 히터 등등 그리고 전기 필요한 러닝머신 같은 경우도 있으니 전기세... 유지보수비 당연히 든다 언제까지? 헬스장 문 닫을 때까지,,, 

아주아주 넉넉한 마음씨를 가지거나 부자가 아니라면 회원권 만들어서 회원들에게만 서비스 제공하겠죠?? 나라면 그럴듯

회원권이 API Key입니다 

API Key = 우리 회원

내 서버 = 헬스장

API = 운동 기구

비용 = 비용

간혹 API Key 없을 수도 있다는데 저렇게 생각하면 진짜 있을까 싶기는 하다 (내 기준)

 

우리 API 이용하고 싶니

---

동기님이 올려주신 레퍼런스 보고 추가++

https://evan-moon.github.io/2020/04/07/about-restful-api/

 

응답으로 오는 리소스는 원본 리소스가 아니다 그냥 표현을 한거다

헤더에  Content-Type을 사용하면 어떤 방식으로 표현된 상태인지 알려줄 수 있다

REST는 리소스의 상태 표현

URI는 리소스 계층

실제로 하려는 행위 -> HTTP 메소드로 표현

 

 

++ REST는 아키텍처 가이드 라인

아키텍처는 건축용어에서 유래됐는데 설계도 정도로 이해하면 된다