API와 REST API

0.

이전 섹션에서 외부 서비스인 STRIPE를 이용하여

신용카드 결제 기능을 웹사이트에 구현했었다.

 

이 강의의 첫 번재 강의 섹션인

시작하기 섹션에서 우리는 웹 개발자로서

웹사이트를 구축할 수 있고

웹 서비스 또는 API도 구축할 수 있다고 언급했었다.

 

그리고 이제는 이 두 표현의 차이가 무엇인지 강조하고 싶다.

우리가 웹사이트를 만들 때에는, 

프론트엔드든 프+백엔드인든 HTML콘텐트를 방문자에게 최종적으로 전달하는 것이 목표이다.

그렇기 때문에 Response에는 최종적으로 HTML 코드가 전달된다.

그리고 이 HTML코드를 웹사이트가 방문자에게 시각적인 형태로 표시해준다.

 

반면에 Web Sevcies / APIs는 

화면에 페이지를 보여주는 것이 최종적인 목표가 아니다.

Stripe의 경우는 신용카드 거래라는 Action을 제공해주었고

Google Maps의 경우는 지도의 정보를 json형태로 제공해주었다.

 

따라서 자체적인 웹서비스를 구축하고 API를 만든다는 것은

데이터를 교환하고 그 서비스가 우리에게 어떤 작업을 해준다는 것에 관한 것이다.

HTML코드 반환이 아닌,

서버에서 수행해야할 작업을 지정하고 반환되는 데이터들을 지정해주는 과정이다.

 

이런 서비스를 구축하고 이용해야하는 이유는

우리가 핵심 비즈니스 논리에 집중하고 다른 기능을 만들고 유지보수하는데 

시간을 쏟지 않기 위함이다.

 

---

 

1.

이전에 우리는 익스프레스나 스프라이프처럼 서드파티패키지를 사용하였다.

이걸 결과적으로 우리는 '서비스'라고 부를 수 있었다.

 

우리 프로젝트에서 사용하는 특정기능이 제공되고

또 패키지 안에 들어있는 API도 있었다.

API는 웹서비스에 대한 코드 간의 연결다리 역할을 하는 일반적인 용어이다.

 

따라서 서비스와 API에 대해 이야기 할 떄,

특정 API를 제공하는 써드파티 패키지도 존재했던 반면

URL에 request를 보내고 response를 받는 URL-based API 또한

서비스라고 칭했다.

 

그리고 스트라이프의 경우에

서비스 공급자가 제공하는 JS패키지도 사용할 수 있었고

패키지의 내부에 웹API와 통신하는 기능도 패키지가 대신해주었다.

 

---

 

2.

이제 JS패키지의 경우엔

API는 메소드와 객체와 속성을 모아놓은 형태로 문서화 되어 

우리 코드안에서 사용할 수 있도록 Exposed되었다.

 

그리고 우리가 이런 패키지를 자체적으로 구축하고 싶다면

우리는 Front-end와 JS개발 그리고 npm와 관련된 지식을 더 배워야 할 것이다.

 

패키지를 만드는 것은 개발자로서 당신이 할 수는 있지만

꼭 해야만 하는 것은 아니다.

 

---

3.

이번 섹션에서는 

 

웹 개발자가 해야하는 것은

웹 개발자로서 많이 수행해야할 URL관련 요청과 응답을 받는 과정인

URL based API 자체를 만드는 과정을 알아볼 것이다.

 

 

이런 URLbased API의 특징은

다양한 HTTP method를 사용해서 다양한 URL로

전송된 서로다른 요청이 -> 서로 다른 요청을 트리거하고

-> 서로 다른 응답을 반환한다는 것이다.

 

뭘 많이 배울것은 아니고

기존에 배웠던 내용에 몇 개념을 더 얹을 뿐이다.

 

---

 

4.

이제부터 URL based API를 API라고 칭하도록 하겠다.

HTML페이지가 아닌 데이터를 보내는 기능만을 API라고 하자는 것이다.

 

API와 웹서비스를 구축해야할 때는 언제인가?

 

이는 웹사이트의 목적에 따라 달라지는데,

한발 물러서서 

"Classic Website"이 필요한 경우를 알아보자.

 

기존의 Classic Website가 필요한 경우는

방문자에게 자신의 콘텐츠를 보여주는 경우이다.

온라인 상점의 경우는 웹사이트가 주요 제품이고, 

사람들은 이 웹사이트에서 물건을 보고 구매할 수 있다.

 

그렇기 때문에 부트캠프가면 쇼핑몰부터 만드는 것이다.

 

----

 

5.

하지만 WebAPI나 WebService가 필요하는 경우는

Stripe같은 경우이다. 우리가 서비스를 구축하고

제공하고, 이러한 액션자체을 다른 개발자나 소비자에게 제공하는 것.

혹은 우리가 다른 프로젝트에서 기존의 작업물을 사용하고 싶을때이다.

 

그에 비해 Data APIs/ Services의 경우도 있는데,

DB에 대한 CRUD작업을 수행하는 API를 만들수도 있고

백엔드없이 다른 클라이언트가 데이터에 접근하거나

웹페이지+데스크탑앱+모바일앱+게임서버 와 같이 다양한 형태의 크로스플랫폼을 구현하고 싶을 때는

이러한 Data API를 필요로 하는 경우도 있다.

 

Swift같은 다른 언어를 이용해서 모바일앱을 구현하는 경우에는 HTML코드를 사용하지 않는데,

이러한 경우가 Data API를 만들기 좋은 경우이다.

 

---

 

6.

이제 이러한 경우에 REST API가 사용될 차례이다.

 

REST API란

HTTP 프로토콜을 기반으로 리소스를 정의하고.

URL 및 HTTP 메서드(GET, POST, PUT, DELETE 등)을 활용하여 

URL 기반 API를 구축하는데 사용되는 표준적인 아키텍처 스타일이고,

이러한 원칙을 지켜서 만든 API를 RESTful API라고 한다.

 

---

 

7.

 

1990년대 후반, World Wide Web의 설계원칙을 정립하기 위하여

HTTP 1.0, 1.1의 표준화 과정에 참가한 로이필딩교수에 의해 고안되었다.

XML을 기반으로 하는 SOAP API를 대체하는 현대 웹서비스의 설계 표준이며

GraphQL, gRPC등의 대안 기술과 함께 계속해서 쓰이고 있다.

 

- 클라이언트와 서버의 명확한 분리

- Statelessness - 각 요청은 독립적, 서버는 이전 요청의 정보를 저장하지 않음

- Cacheable - Response Data는 캐싱이 가능해야 한다. 두번 계산시키지 말라

- Layered System 

- Uniform Interface, 일관된 인터페이스 제공

- Code on Demand : 필요시 서버에서 실행가능한 코드를 클라이언트에 전달할 수 있음

등이 있다.

 

---

 

8.

REST는 

Representational State Transfer를 의미한다.

표현가능한 상태의 전달이라는 의미이지만

사실 이름은 그렇게 중요하지는 않고

 

실제로 작동하는 방식과 REST API의 설계방식을 아는게 중요하다.

 

핵심적인 규칙은

API "Endpoints"는 URL+HttpMethod의 조합으로 규정되어야 한다는 점이다.

 

GET /cars 라는 API를 요청받으면,

Http Method로 GET이 들어왔고, URL path로는 /cars가 들어왔으므로

사용가능한 car의 list를 반환하는 형식으로

API는 설계되어야 한다.

 

구체적으로 예를 들자면

엔카처럼 자동차 렌탈샵을 사용하기 위해서 Web api를 구축하고 싶다고 할 때,

 

- GET /cars 는 cars라는 list를 response로 반환하는 기능

- POST /rental 은 rental request를 Create및 Store하고 응답을 보내는 기능

- PUT /rental/:id 는 기존 rental data에 Overwrite하는 기능

- PATCH /users/:id는 현재 서비스를 이용하는 유저데이터를 업데이트

- DELETE /rental/:id는 rental request를 제거(취소)하는 기능

 

의 형태로 Http Method + URL 형태로 Action & Respond하는 제공하는 것이다.

 

---

 

9.

비록 이러한 많은 기능을 API로 제공할 수 있지만,

결국 실제로 일어나는 일은 백엔드에서 일어난다.

API가 제공하는 Endpoint는 서버내부에서 사용되는 것이 정의되고

어떠한 코드와 라우트를 통해 request와 연결되는 과정이 반드시 필요하다.

 

그렇기 때문에 이러한 백엔드에서 노출되는 Endpoint가

얼마나 Descriptive한지, 명확하게 기능을 제공하고 설명하는 형태로

API가 작성되도록 해야한다.

 

 

10.

REST API는 web API의 building pattern이고 architecture pattern이다.

그리고 그 이외에도 SOAP APIs와 GraphQL APIs도 있지만

REST APIS가 가장 일반적인 API형식이고

이후에 나온 API들에 영향을 미쳤다.

 

11.

우리는 Nodejs로 이러한 Web API를 구축해보겠지만,

MySQL로도 Web API를 만들수도 있고

다른 플랫폼에서도 형식만 갖추면 RESTful API가 된다.