다음 프로젝트를 위해 선택할 것 [2023]

API를 다룰 때 종종 REST 및 gRPC를 접하게 됩니다. Rest가 수년 동안 이 분야를 지배했지만 gRPC는 가치 있는 경쟁자임이 입증되었습니다.

Rest와 gPRC는 API를 설계할 수 있는 서로 다른 두 가지 방법입니다. API는 다른 컴퓨터에 상주하거나 다른 언어로 작성된 복잡한 시스템을 나타낼 수 있는 서비스 간의 통신 다리 역할을 합니다.

이 기사에서는 Rest와 gRPC를 모두 소개하고 유사점, 차이점 및 각각을 사용하는 위치를 공유합니다.

휴식이란 무엇입니까?

나머지 (Representational State Transfer)는 소프트웨어 구성 요소가 데이터를 교환하는 방법에 대한 규칙을 지시하는 아키텍처 소프트웨어 접근 방식입니다. Rest는 웹의 표준 통신 프로토콜인 HTTP를 기반으로 합니다.

REST 아키텍처 스타일을 기반으로 하는 모든 API를 RESTful API라고 합니다. 한편, REST 아키텍처 설계를 따르는 웹 서비스를 RESTful 웹 서비스라고 합니다.

REST 아키텍처 스타일은 이러한 원칙을 따릅니다.

균일한 인터페이스: 서버는 표준 형식으로 데이터를 전송해야 합니다. 그러나 전송되는 데이터는 서버 응용 프로그램 리소스의 내부 표현과 다른 형식일 수 있습니다.
상태 비저장: 서버는 이전 요청에 관계없이 모든 클라이언트 요청을 독립적으로 완료해야 합니다. 리소스에 대한 클라이언트 요청은 임의의 순서일 수 있으며 모든 요청은 나머지 요청과 격리됩니다.
계층화된 시스템: 서버와 클라이언트 사이에 인증된 중개자 계층을 제공합니다. 클라이언트는 이러한 인증된 중개자와 연결할 수 있으며 여전히 서버로부터 응답을 받을 수 있습니다.
캐시 가능성: 일부 응답은 응답 시간을 개선하기 위해 중개자 또는 클라이언트에 저장됩니다.
주문형 코드: 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 일시적으로 클라이언트 기능을 사용자 지정하거나 확장합니다.

REST의 이점

확장성: REST API는 클라이언트-서버 상호 작용을 최적화하기 때문에 확장성으로 잘 알려져 있습니다. 캐싱 및 상태 비저장은 서버 부하를 줄이는 주요 기능입니다.
유연성: RESTful API는 완전한 클라이언트-서버 분리를 제공합니다. 이러한 서비스는 독립적으로 발전할 수 있는 다양한 서버 구성 요소를 분리하고 단순화합니다.
독립성: API 디자인에 영향을 주지 않고 다른 프로그래밍 언어로 서버 및 클라이언트 애플리케이션을 작성할 수 있습니다.

나머지 사용 사례

웹 API
웹 서비스
마이크로서비스 아키텍처

gRPC란?

gRPC 모든 환경에서 실행할 수 있는 RPC(원격 프로시저 호출) 프레임워크입니다. 이 오픈 소스 프레임워크는 데이터 센터 전체와 내부에서 서비스를 효율적으로 연결할 수 있는 고성능 프로토콜로 설계되었습니다.

클라이언트 앱은 마치 로컬 개체인 것처럼 다른 시스템의 서버 앱에서 메서드를 호출할 수 있습니다. gRPC를 사용하여 서비스를 정의하고 해당 매개변수 및 반환 유형을 사용하여 원격으로 호출할 수 있는 메서드를 지정합니다.

gRPC에는 연결 가능한 상태 확인, 인증, 부하 분산 및 추적 지원이 있습니다. 이 프레임워크는 데이터 전송을 위해 HTTP 2 및 프로토콜 버퍼를 사용합니다. 데이터를 교환할 때 리소스 URL 대신 프로시저가 호출됩니다.

gRPC의 이점

확장 가능: gRPC를 사용하면 단일 명령으로 런타임 환경을 설치하고 초당 수백만 RPC 확장을 시작할 수 있습니다.
간단한 서비스 정의: 프로토콜 버퍼를 사용하여 서비스를 정의하고 실행하십시오.
교차 플랫폼: 이 프레임워크는 다양한 플랫폼과 언어에 대해 관용적인 클라이언트 및 서버 스텁을 생성합니다.
양방향 스트리밍 및 통합 인증.

gRPC의 사용 사례

웹 API
웹 서비스
스트리밍 애플리케이션
마이크로서비스 커뮤니케이션

REST와 gRPC의 유사점

데이터 교환 메커니즘: 두 아키텍처 설계 모두 서버와 클라이언트가 데이터를 교환할 수 있도록 합니다. 그러나 이 데이터는 특정 규칙에 따라 공유됩니다.
확장 가능한 분산 시스템에 적합: REST 및 gRPC 모두의 비동기식 통신 및 상태 비저장 설계를 통해 API를 쉽게 확장할 수 있습니다.
HTTP 기반 통신 사용: 둘 다 웹에서 가장 선호되는 통신 프로토콜인 HTTP를 사용합니다.
유연성: 다양한 프로그래밍 언어 및 기술과 함께 REST 및 gRPC를 사용할 수 있습니다.

REST와 gRPC: 심층 분석 비교

REST 및 gRPC 서비스는 다음과 같은 차이점이 있습니다.

데이터 교환

REST API에서 한 소프트웨어 구성 요소에서 다른 구성 요소로 전달되는 데이터는 JSON 형식으로 표현되어야 합니다. JSON은 데이터 교환을 위해 직렬화되고 프로그래밍 언어로 변환되어야 합니다. 그러나 Rest API는 HTML 및 XML과 같은 데이터 형식도 교환할 수 있습니다.

gRPC는 기본적으로 프로토콜 버퍼 형식을 사용합니다. 그러나 기본적으로 JSON도 지원합니다. 프로토콜 버퍼는 사람이 읽을 수 없습니다. 서버는 프로토콜 버퍼 인터페이스 설명 언어를 사용하여 데이터 구조를 정의합니다. 그런 다음 gPRC는 데이터 구조를 이진 형식으로 직렬화합니다. 그런 다음 데이터를 지정된 프로그래밍 언어로 역직렬화합니다.

커뮤니케이션 모델

REST에서 클라이언트는 서버에 단일 요청을 보냅니다. 그런 다음 서버는 응답으로 응답을 보냅니다. 클라이언트는 작업을 계속하기 전에 서버의 응답을 기다려야 합니다. 요청-응답 모델입니다.

gRPC에서 클라이언트는 단일 또는 다중 서버 요청을 보낼 수 있으므로 각각 단일 또는 다중 응답이 생성됩니다. 데이터 연결은 다대다, 다대일, 일대다 또는 일대일일 수 있습니다. gRPC는 클라이언트-응답 통신 모델을 사용합니다.

코드 생성

gRPC에는 기본 제공 서버 측 및 클라이언트 측 코드 생성 기능이 있습니다. 프로토콜 버퍼 컴파일러를 통해 다양한 언어로 이러한 기능을 찾을 수 있습니다. gRPC는 proto 파일에서 구조를 정의한 후 서버 측 및 클라이언트 측 코드를 생성합니다.

REST에는 내장 코드 생성 기능이 없습니다. 이 기능이 필요한 경우 타사 도구를 사용할 수 있습니다.

HTTP 프로토콜

REST API는 HTTP 1.1을 사용합니다. REST 서비스에서 요청을 보내려면 리소스 URL이 필요합니다. HTTP 1은 컴퓨터와 웹 서버 간에 정보를 보냅니다. REST 서비스의 리소스 URL은 클라이언트에 표시됩니다. API 디자이너는 리소스 URL의 구조를 제어합니다.

gRPC는 HTTP 2를 사용합니다. 이 HTTP 버전은 2015년에 도입되었으며 Internet Explorer, Safari 및 Chrome과 같은 브라우저에서 사용됩니다. 모든 것을 일반 텍스트로 유지하는 HTTP 1과 달리 이 최신 형식은 이진 형식 캡슐화를 활용하여 더 많은 데이터 전달 옵션을 제공하고 전체 프로세스 속도를 높입니다.

페이로드 데이터 구조

REST는 XML 또는 JSON을 사용하여 데이터를 보내고 받습니다. JSON은 유연하고 구조가 필요하지 않기 때문에 REST에서 동적 데이터를 전송하는 데 가장 많이 사용되는 형식입니다. JSON 데이터도 사람이 읽을 수 있습니다. JSON의 유일한 문제는 데이터 전송 중에 직렬화되고 변환되어야 하므로 그렇게 빠르지 않다는 것입니다.

gRPC는 프로토콜 버퍼를 사용하여 페이로드 데이터를 직렬화합니다. 이것은 메시지 데이터를 줄이는 고도로 압축된 형식입니다. 이 프레임워크는 Protobuf를 사용하여 강력한 형식의 메시지를 클라이언트 및 서버의 프로그래밍 언어로 자동 변환합니다.

브라우저 지원

REST는 HTTP 1.1을 사용하므로 모든 브라우저에서 지원됩니다. 따라서 웹 서비스 및 API를 위한 완벽한 선택입니다.

gRPC는 HTTP 2를 기반으로 하므로 브라우저에 대한 지원이 제한됩니다. 모든 브라우저를 지원하려면 gRPC-web을 프록시 계층으로 추가해야 합니다. 이러한 이유로 gRPC는 대부분 내부 시스템에 채택됩니다.

클라이언트-서버 결합

REST는 느슨하게 결합된 아키텍처 설계입니다. 이는 클라이언트와 서버가 서로의 구현에 대해 알 필요가 없음을 의미합니다. 이 기능을 사용하면 서버 정의를 변경할 때 클라이언트 코드를 변경할 필요가 없으므로 시간이 지남에 따라 RESTful API를 더 쉽게 발전시킬 수 있습니다.

gRPC는 서버와 클라이언트가 동일한 proto 파일에 액세스해야 하는 긴밀하게 결합된 프레임워크입니다. 파일을 변경해야 하는 경우 서버와 클라이언트도 업데이트해야 합니다.

나머지 대 gRPC

기능RESTgRPCHTTP 프로토콜HTTP 1.1HTTP 2브라우저 지원HTTP 1.1을 사용하므로 모든 브라우저 지원 2코드 생성제3자 도구 사용내장 코드 생성 기능디자인 접근 엔터티 지향 설계서비스 지향 접근데이터 액세스리소스 URL서비스 호출양방향 데이터 스트리밍사용 불가사용 가능구현하는 데 일반적인 소프트웨어가 필요하지 않음 클라이언트 또는 서버 측 gRPC 소프트웨어의 REST는 클라이언트 측과 서버 측 모두에 필요합니다. 통신 모델단일 클라이언트는 단일 서버와 통신합니다. 하나의 클라이언트와 같은 다중 통신 모델은 여러 서버에 요청을 보내거나, 하나의 서버가 여러 클라이언트와 통신하거나, 하나의 서버가 하나의 클라이언트와 통신합니다.

REST를 사용하는 경우

RESTful API 및 웹 서비스는 매우 인기가 있습니다. RESTful 서비스는 구현, 데이터 구조화, 유연하고 읽기 쉽습니다. 다음과 같은 경우에 REST를 사용할 수 있습니다.

웹 기반 아키텍처: REST 아키텍처 디자인을 사용하여 웹, 모바일 및 다중 플랫폼 API를 생성할 수 있습니다.
간단한 데이터 통신: REST는 읽기 쉬운 데이터 형식인 JSON을 사용합니다.
공용 API: 대중이 데이터를 소비하고 API를 사용하려는 경우 가독성 기능으로 인해 REST가 좋은 선택이 될 것입니다.

gRPC를 사용하는 경우

gRPC는 RESTful 서비스만큼 인기가 없습니다. 그러나 다음 응용 프로그램에서 눈에 띄게 만드는 고유한 기능도 있습니다.

다중 언어 시스템: gRPC는 다양한 프로그래밍 언어로 작성되고 API가 변경될 가능성이 없는 마이크로서비스 아키텍처에 적합합니다.
마이크로서비스 연결: 양방향 스트리밍 및 낮은 브라우저 지원과 같은 기능으로 인해 gRPC는 내부 API에 적합합니다.
실시간 스트리밍 네트워크: 대용량 데이터 로드를 처리하고 실시간 스트리밍이 필요한 내부 서비스와 함께 gRPC를 사용할 수 있습니다.

저자 의견

gRPC에는 사물 인터넷과 같은 애플리케이션에서 REST를 압도할 수 있는 몇 가지 특정 기능이 있지만 가독성, 유연성 및 광범위한 채택으로 인해 후자가 승리합니다. gRPC의 낮은 브라우저 지원으로 인해 웹 서비스를 구축하려는 개발자에게는 그리 좋은 선택이 아닙니다.

RESTful 서비스에 대한 보편적인 지원 덕분에 REST는 웹 및 마이크로서비스 통합을 위한 이상적인 API 아키텍처 스타일이 되었습니다.

결론

REST 및 gRPC는 다음 API를 빌드할 때 선택할 수 있는 많은 API 아키텍처 스타일 중 하나입니다. 최종 선택은 빌드하려는 제품에 따라 다릅니다. RESTful 서비스는 공용 API를 구축할 때 완벽하게 적합하며 gRPC는 브라우저 지원이 필요하지 않은 모바일 애플리케이션과 같은 서비스에 적합합니다.

다음으로 Java를 사용하여 처음부터 gRPC를 만드는 방법에 대한 기사를 확인하십시오.