API 란?

API는 Application Programming Interface 의 줄임말

두 독립적인 소프트웨어가 서로 Communicate 할 방법을 설명해 놓은 것

API 를 사용해서 회사의 데이터와 기능을 내외부 개발자들이 사용 가능케 할 수 있음

일반적으로 Internal API는 RPC API 로. External (Web) API 는 HTTP API 로 구축

gRPC: 구글에서 개발한 대표적인 RPC API Framework

구글 내부의 마이크로 서비스들 간 통신을 위해 만든 Internal API

이를 외부에 공개하여 다른 사람들도 사용하게 함

REST API: 대부분의 HTTP API 가 따르는 아키텍처 스타일 (제약 조건) 을 만족하는 API

샌드버드는 Chat 기능을 지원해주는 API로 사업을 하는 회사

페이스북이나 구글도 자기들이 제공하는 서비스에 프로그래밍적으로 접근할 수 있게 API를 열어놓는다.

소프트웨어 간 이야기하는 일을 크게 두 가지로 나누어 볼 수 있다.

1. 회사 데이터 센터 안에서 마이크로 서비스들끼리 통신하는 경우(Internal API, 대부분 RPC 기반 API)
2. 외부에 있는 사람들이 API를 사용(External Web API, 대부분 HTTP 기반 API)

REST API는 단지 스타일 가이드이다.

강제성이 있는건 아니지만, 룰을 지키면 해당 API를 REST API로 부를 수 있게 되는 것이고,

Best Practice 스타일가이드라인을 따랐을 때 여러가지 이점들이 있다.

API 비교

우측은 HTTP API로, REST API 규칙을 지킨 형태이다.
gRPC 쪽이 더 세세한 요구사항이 있다.

계약

gRPC는 proto 파일로 계약을 맺어야 되는데, HTTP API는 그것이 선택사항이다.

규범

gRPC는 엄격한 데 반해서 REST API는 느슨하다
(=구현 방식이 다양하다)

프로토콜

gRPC는 HTTP/2.0을 사용하고, REST API는 제약이 없다.

REST API 란?

💡 REST API란 RESTful한 API를 말하며 일련의 특징과 규칙 등을 지키는 API를 일컫는다

REST API에서 Resource는 추상적인 개념이다. 실제 클라이언트가 답을 받았을 때, 그 형태는 매번 다를 수가 있다. 그 표현 형태를 Representation 이라 한다.

리소스가 실제로 어떤 형태로, 어떤 DB에 저장이 되어있는지는 클라이언트는 알 수도, 알 필요도 없다.

그러나 그 정보의 한 Representation이 클라이언트에게 전해진다.

Web API 의 한 종류

REST 디자인 프린시플을 따르는 API 를 REST API 라고 함

• REST 는 Representational State Transfer Architectural Style 의 출임말
• RESTful API 라고도 불림

2000년도에 Dr. Roy Fielding 의 박사논문에서 최초로 등장

REST 는 개발자에게 높은 자유도를 보장.

• Protocol이 아니라 Design Principle이기 때문에 개발자에게 높은 자유도를 보장한다
• 그 자유도 덕분에 여러 Component 들을 연결하거나 Microservices architecture 에서 많이 사용됨

클라이언트. 서버. 리소스, 표현(Representation)으로 구성

• 예) 내 브라우저 (클라이언트)가 기상청 API 를 통해 날씨 (리소스) 정보를 요청하면 기상청 서버가 날씨 정보를 JSON 형태로 제공

REST 디자인 원칙

1. Client-server decoupling.

   💡 서로의 존재조차 모르고 신경 쓰지 않는다

   전송될 데이터가 어떻게 사용 될지는 전혀 신경쓰지 않는다.

   클라이언트와 서버 어플리케이션이 완벽히 decouple 되어 있어야함.

   클라이언트가 알아야 할 유일한 정보는 필요한 리소스의 URI 임.

   마찬가지로 서버도 클라이언트가 보낸 리퀘스트에 리스폰스만 보낼 수 있음.

2. Statelessness.

   💡 상대방에 대한 기존 정보를 저장하지 않는다

   stateless의 장점

   • 다른 머신 노드를 통해 리퀘스트를 프로세스 할 수 있다
     • 서버 하나가 다운 된 경우 다른 서버를 spin up 하여 마운틴 하는 등
   • 디버깅에 용이하다.
     • 리퀘스트가 실패 했을 때, 해당 리퀘스트만 살피면 된다.
     • 리퀘스트에 모든 정보가 담겨있기 때문.
     • stateful 한 통신의 경우 요청에 실패했을 때, 과거의 요청을 모두 봐야한다.
     • 만일 세션이 한 달 혹은 그 이상 유지된 경우. 디버깅 과정이 힘들어진다.

   REST APIs 는 stateless 해야함.

   각각의 리퀘스트가 그 리퀘스트를 처리하는데 필요한 모든 정보를 가지고 있어야 함.

   서버 사이드 세션이 필요없음.

   서버는 클라이언트 리퀘스트에 관련된 정보를 저장할 수 없음.

3. Uniform Interface.

   💡 REST API의 Uniform Interface를 지켰다면 각각의 API가 구동하는 방식이 거의 일치한다.

   단지 그 리소스의 종류와 리소스가 가지고 있는 데이터의 내용만 다를 뿐이다.

   같은 리소스에 대한 리퀘스트는 항상 같아야함.

   한 리소스에 대한 데이터는 모두 같은 Uniform Resource Identifier (URI)에 있어야 함.

   리소스는 클라이언트가 필요한 최소한의 데이터만 가지고 있어야함

4. Cacheability.

   💡 1~3번을 지키면 4번은 거의 따라온다

   가능한 경우 클라이언트나 서버 측에서 자원을 캐시할 수 있도록 해야함.

   또한 서버 응답에는 전송된 자원에 대해 캐싱이 허용되는지 여부에 대한 정보가 포함되어야 함.

   이를 통해 클라이언트 측 성능을 개선하고 서버 측 확장성을 높이는 것이 목표.

5. Layered system architecture.

   REST API 에서 호출 및 응답은 서로 다른 계층을 통해 이루어짐.

   원칙적으로 클라이언트와 서버 애플리케이션이 직접 연결된다고 가정해서는 안 됨.

   통신 루프에는 다양한 중간 매개체가 있을 수 있음.

   REST API 는 클라이언트나 서버가 최종 애플리케이션 또는 중간 매개체와 통신하는지 구분할 수 없도록 설계되어야 함.

6. Code on demand (optional).

   💡 정적인 자원이란?

   동적인 기능(function, Java applet)이 없다는 것

   REST API 는 일반적으로 정적인 자원을 보내지만 특정 경우에는 응답에 실행할 수 있는 코드도 포함 가능.

   • 예: Java 애플릿

   이러한 경우 코드는 요청 시에만 실행되어야 함