gRPC VS REST

gRPC란 무엇인가

gRPC는 CNCF에서 관리하는 오픈소스 API 아키텍쳐 및 시스템입니다. 원격 프로시저 호출(RPC) 모델을 기반으로 동작하고 gRPC는 RPC 모델의 특정 구현체입니다.

RPC에서 클라이언트-서버 통신은 클라이언트 API 요청이 로컬 작업이거나 요청이 내부 서버 코드인 것처럼 작동합니다. RPC에서 클라이언트는 서버의 프로세스로 요청을 전송합니다. 서버 프로세스는 항상 원격 호출을 수신 대기 중인 상태로 유지됩니다. 요청에는 직접적으로 호출할 서버 함수와 전달할 파라미터가 포함됩니다. RPC API는 HTTP, TCP 또는 UDP와 같은 프로토콜을 기본 데이터 교환 메커니즘으로 사용합니다.

gRPC와 RPC는 어떻게 다른가

gRPC는 몇 가지 최적화와 함께 기존 RPC를 구현하는 시스템입니다. 예를 들어 gRPC는 데이터 전송에 Protocol Buffer와 HTTP 2를 사용합니다. 또한 개발자의 데이터 교환 메커니즘을 추상화합니다. 예를 들어 널리 사용되는 또 다른 RPC API 구현인 OpenAPI를 사용할 때는 개발자가 RPC 개념을 HTTP 프로토콜에 매핑해야 합니다. gRPC는 기본 HTTP 통신을 추상화하고, 이러한 최적화 덕에 gRPC는 다른 RPC 구현보다 더 빠르고 쉽게 구현할 수 있으며 웹 친화적입니다.

REST란 무엇인가

REST는 소프트웨어 구성 요소 간 데이터 교환을 위한 일련의 규칙을 정의하는 소프트웨어 아키텍처 접근 방식입니다. REST는 웹의 표준 통신 프로토콜인 HTTP를 기반으로 합니다. RESTful API는 생성, 읽기, 업데이트 및 삭제 작업에 POST, GET, PUT, DELETE, 와 같은 HTTP Method를 사용하여 클라이언트와 서버 간의 통신을 관리합니다. 서버 측 리소스는 엔드포인트라고 하는 URL로 식별됩니다.

gRPC와 REST는 API 개발에 대한 2가지 다른 접근 방식입니다. API의 작동 방식은 서로 다른 애플리케이션이나 소프트웨어가 통신하는 방식에 대한 합의가 이루어져있습니다. API가 없다면 서로 다른 애플리케이션이나 소프트웨어 서비스가 통신하는 방식에 대한 공동의 합의가 이루어지지 않습니다. API 아키텍처에는 gRPC 및 REST 같은 다양한 유형이 있습니다.

gRPC와 REST의 유사점

데이터 교환 메커니즘
- 클라이언트와 서버라는 두 소프트웨어 구성 요소는 두 API 모두에서 공유 규칙 세트에 따라 통신하고 데이터를 교환할 수 있습니다.
HTTP 기반 통신
- 웹에서 선호되는 효율적인 통신 프로토콜인 HTTP 요청-응답 메커니즘을 통해 데이터를 전달합니다.
구현 유연성
- REST와 gRPC 모두 다양한 프로그래밍 언어로 구현할 수 있습니다.
확장 가능한 분산 시스템에 대한 적합성
- gRPC와 REST 모두 다음을 사용합니다.
  - 비동기식 통신 : 클라이언트와 서버에서 작업을 중단하지 않고 통신할 수 있음
  - 무상태 설계 : 서버에서 클라이언트 상태를 기억할 필요가 없음

아키텍처 원칙 : gRPC 와 REST

통신 모델
- REST API
  - 클라이언트는 단일 REST API 요청을 서버에 전송
  - 서버는 이에 대한 응답으로 단일 응답을 보냄
  - 클라이언트에서는 작업을 계속하기 전에 서버가 응답할 때까지 기다려야 합니다.
- gRPC
  - 클라이언트가 하나 또는 여러 개의 API 요청을 서버에 보낼 수 있습니다.
  - 서버에서 하나 또는 여러 개의 응답이 발생할 수 있습니다.
  - 데이터 연결은 단방향, 서버 스트리밍, 클라이언트 스트리밍, 또는 양방향 스트리밍 일 수 있습니다.
  - 이 메커니즘은 클라이언트-응답 통신 모델이며, gRPC가 HTTP2를 기반으로 하기 때문에 가능합니다.
서버에서 직접적으로 호출 가능한 작업
- REST API
  - URL로 정의된 서버 리소스에 대해 클라이언트에서 사용할 수 있는 제한된 HTTP 요청 동사 세트가 있습니다.
  - 클라이언트는 리소스 자체를 직접적으로 호출합니다. POST /orders <headers> (customer_id. item_id, item_quantity) -> order_id
- gRPC
  - gRPC API에서 직접적으로 호출 가능한 서버 작업은 함수 또는 프로시저라고도 하는 서비스에 의해 정의됩니다.
  - gRPC 클라이언트는 애플리케이션 내에서 내부에서 함수를 직접적으로 호출하는 것처럼 이러한 함수를 간접적으로 호출합니다. createNewOrder(customer_id, item_id, item_quantity) -> order_id
데이터 교환 형식
- REST API
  - 소프트웨어 구성 요소 간에 전달되는 데이터 구조가 일반적으로 JSON 데이터 교환 형식으로 표현됩니다.
  - JSON은 읽기 쉽고 유연하지만 직렬화해야 하고 프로그래밍 언어로 번역해야 합니다.
- gRPC
  - 기본적으로 Protocol Buffer(Protobuf) 형식을 사용하지만 기본 JSON 지원도 제공합니다.
  - 서버는 프로토타입 사양 파일에서 Protocol Buffer 인터페이스 설명 언어를 사용하여 데이터 구조를 정의합니다.
  - gRPC는 구조를 바이너리 형식으로 직렬화한 다음 지정된 프로그래밍 언어로 역직렬화합니다. 이 메커니즘은 전송 중에 압축되지 않는 JSON을 사용하는 것보다 더 빠릅니다.

주요 차이점 : gRPC와 REST

클라이언트 서버 커플링
- REST
  - 느슨하게 결합되기 때문에 클라이언트와 서버가 상대의 구현에 대해 전혀 알 필요가 없습니다.
  - 느슨한 결합으로 인해 시간이 지남에 따라 API가 더 쉽게 발전할 수 있습니다.
  - 서버 정의를 변경한다고 해서 반드시 클라이언트에서 코드를 변경해야 하는 것은 아니기 때문입니다.
- gRPC
  - 긴밀하게 결합되기 때문에 클라이언트와 서버에서 동일한 proto 파일에 엑세스할 수 있어야 합니다.
  - 파일을 업데이트하려면 서버와 클라이언트 모두에서 업데이트가 필요합니다.
코드 생성
- REST
  - 내장된 코드 생성 메커니즘을 제공하지 않으므로 이 기능이 필요한 경우 서드 파티 도구를 추가로 사용해야 합니다.
- gRPC
  - 다양한 클라이언트 측 및 서버 측 네이티브 코드 생성 기능이 내장되어 잇습니다.
  - Protocol Buffer 컴파일러인 protoc 덕에 여러 언어로 사용할 수 있습니다.
  - proto 파일에서 구조를 정의하면 gRPC가 클라이언트 측 및 서버 측 코드를 생성합니다.
  - 코드가 생성되기 때문에 API 개발에 소요되는 시간이 줄어듭니다.
양방향 스트리밍
- gRPC에서는 가능하지만, REST에서는 불가능합니다.

비교 포인트	gRPC API	REST API
무엇인가	원격 프로시서 호출 클라이언트 서버 통신 모델을 기반으로 API를 만들고 사용하는 시스템	클라이언트와 서버 간의정형 데이터 교환을 정의하는 일련의 규칙
설계 접근 방식	서비스 지향 설계	엔티티 지향 설계
통신 모델	단뱡항, 단일 서버-다중 클라이언트, 단일 클라이언트- 다중 서버, 다중 클라이언트-다중 서버 등 다양한 옵션	단방향, 단일 클라이언트가 단일 서버와 통신합니다.
구현	작동하려면 클라이언트와 서버 모두에 gRPC 소프트웨어가 필요	공통 소프트웨어 없이 다양한 형식으로 구현
데이터 엑세스	서비스 직접 호출	리소스를 정의하는 URL 형태의 여러 엔드포인트
반환된 데이터	ProtocolBuffer 파일에 정의된 서비스의 고정된 반환 유형으로 반환됩니다.	서버에서 정의하는 고정구조 (일반적으로 JSON)으로 반환됩니다.
클라이언트-서버 커플링	긴밀하게 결합됩니다. 클라이언트와 서버 모두에 데이터 형식을 정의하는 동일한 ProtocolBuffer 파일이 필요	느슨하게 결합됩니다. 클라이언트와 서버는 내부 세부 정보 인식X
자동 코드 생성	기본 제공 기능	서드 파티 도구가 필요
양방향 스트리밍	있음	없음
가장 적합한 용도	고성능 또는 데이터 사용량이 많은 마이크로서비스 아키텍처	리소스가 잘 정의된 단순한 데이터 소스