RESTful API가 인기 있는 이유

참고 사이트 https://blog.bytebytego.com/p/why-is-restful-api-so-popular

 

 

https://blog.bytebytego.com/p/why-is-restful-api-so-popular

 

 

API(Application Programming Interface)

두 개의 소프트웨어 컴포넌트가 서로 약속한 정의와 프로토콜을 기반으로 소통할 수 있게 하는 메커니즘.

예를 들면, 기상청 시스템은 일일 기상 정보를 가지고 있고, 당신의 폰에 설치 된 날씨 어플이 API를 통해 이 시스템과 소통하여 일일 날씨 정보를 업데이트해서 보여주는 방식이다.

[출처: AWS]

 

 

REST(REpresentational State Transfer)

대부분의 모바일과 웹 어플리케이션이 서버와 소통하는 API 스탠다드를 일컫는다.

명확한 기준으로 정해진 것은 없으나, 2000년대 초기부터 쓰인 사실 상 표준이라고 할만 한 규칙들은 존재한다.

 

 

RESTful API

REST API Rules
Uniform Interface
Client-Server
Stateless
Cacheable
Layered System
Code on Demand(Optional)

 

REST 기준을 따라는 API를 RESTful API라고 부른다. 실제 사용되는 RESTful API의 예시로는 트윌로(Twillo), 스트라이프(Stripe)와 구글 지도(Google Maps) 등이 있다.

 

 

RESTful API의 기본 구조와 작동 방식

RESTful API는 자원(이후 영문 그대로 '리소스'라고 칭함)을 특정 URI(Uniform Resource Identifiers)에 맞춰서 구조화 하는데, 이는 다음과 같다.

URIs
https://example.com/api/v3/products
https://example.com/api/v3/users

위에서 보듯 리소스는 동사형이 아니라 명사형으로 묶이며, 이에 대상에 대한 정보를 얻기 위한 API에 동사가 들어가서는 안 된다.

https://example.com/api/v3/products (O) https://example.com/api/v3/getAllProducts (X)

 

클라이언트가 HTTP 통해서 리소스와 관련한 요청을 보낼 때에는 다음과 같은 특정한 형식이 있다.

POST /products HTTP/1.1

이는 HTTP 동사(POST)를 포함하고 있으며, 어떤 리소스에 접근하려고 하는 것인지를 명확히 밝히고 있다.

아마 CRUD라는 줄임말을 들어본 적이 있을 텐데, 이를 HTTP 동사로 변환하면

CREATE => POST, READ => GET, UPDATE => PUT, DELETE => DELETE 이다.

요청의 body 부분에 이러한 HTTP 요청 body를 넣을 수있고, 이는 주로 JSON 형태로 인코딩 된 데이터의 payload를 포함하고 있다.

 

클라이언트 측에서 보낸 요청을 서버가 받게 되면, 이를 처리하고 요청에 대한 결과(응답)을 다시 포맷팅하게 되는데, 요청의 첫 줄에는 HTTP 상태 코드를 보내 해당 요청에 대한 간단한 결괏값을 보내게 된다.

 

200번대는 요청이 성공했음을, 400번대는 요청과 관련해 문제가 있었음을(클라이언트 잘못), 500번대는 서버에 문제가 있었다는 것을 의미한다.

 

잘 만들어진 클라이언트라면 500번대의 상태 코드를 받았을 때, 재요청을 보낼 것인지 말 것인지를 선택할 수도 있다.

이렇게 말하는 이유는, 어떤 요청들은 변동될 수 있어서 각별한 주의가 필요하기 때문이다. (??)

API가 idempotent하다면, 같은 요청을 여러번 하는 것이 모두 하나의 요청으로 인식되기도 하는데, 이는 일반적으로 새로운 리소스를 만들기 위한 POST 요청에서는 해당되지 않는다.

 

요청의 body 부분은 선택적이며, 데이터 페이로드를 포함할 수도 있고 안할 수도 있는데, 포함한다면 대부분의 데이터는 JSON 형식으로 포맷팅 된다. 

 

 

REST의 statelss

REST 구현은 항상 stateless를 만족시켜야 하는데, 이는 소통하는 두 개의 구성원들이 서로에 대한 그 어떤 정보도 저장할 필요가 없으며, 모든 요청과 응답은 독립적으로 존재한다는 것을 의미한다.

이는 웹 어플리케이션이 더 잘 동작할 수 있게 해준다.

 

 

API 버전

버전 관리를 통해서 이전 버전과의 호환이 가능하므로, 다음 버전으로 변경할 때에도 사용자들이 다음 버전으로 변경, 적응할 수 있는 충분한 시간이 주어진다. API를 버전화하는 방법에는 여러가지가 있는데, 가장 간단한 것은 URI의 리소스 앞에 버전을 명시하는 것이다.