소프트웨어 개발과 관련하여 REST 와 같은 단어를 들었을 것입니다. REST 는 매우 일반적으로 사용되는 API 아키텍처이며 개발자는 소프트웨어 API를 설계하는 데 널리 사용합니다. 애플리케이션 프로그래밍 인터페이스는 모든 소프트웨어 애플리케이션에 필수적이며 REST 는 API에 사용되는 많은 아키텍처 중 하나입니다.
요즘 g RPC 아키텍처가 인기를 얻고 있으며 전통적으로 REST API 와 관련된 몇 가지 문제를 해결한다고 주장합니다. 그러나 그들은 어디에서 다른가? 그리고 어떤 것을 애플리케이션에 사용해야 합니까? 이러한 질문에 대한 답을 알기 위해서는 g RPC 와 REST 가 어떤 시나리오에서 더 잘 수행되는지에 대해 더 많이 이해해야 합니다. 그러나 모든 것을 다루기 전에 API가 무엇이며 마이크로 서비스를 위해 테이블에 제공하는 것이 무엇인지 살펴보겠습니다.
API란?
소프트웨어 앱은 기술 중재자 역할을 하는 API인 응용 프로그래밍 인터페이스를 사용하여 서로 상호 작용하고 통신할 수 있습니다. API는 사용자의 요청을 시스템으로 보내고 시스템에서 응답을 받는 역할을 합니다.
온라인으로 전화를 주문한다고 상상해보십시오. 웹에 연결된 사이트로 이동하면 쿼리에 대한 정보가 서버로 전송됩니다. 그런 다음 서버는 정보를 가져와 분석하고 필요한 조치를 취한 후 화면에 표시된 세부 정보로 회신합니다. 이것은 API를 통해 가능합니다.
API는 이러한 클라이언트 요청을 수행하는 방법, 사용할 데이터 구조 및 클라이언트가 준수해야 하는 표준에 대해 설명합니다. 또한 한 프로그램이 다른 프로그램으로 보낼 수 있는 쿼리의 종류를 설명합니다. g RPC 와 REST 아키텍처 스타일 모두 API 설계에 널리 사용됩니다.
API 및 마이크로서비스
애플리케이션은 모놀리식 아키텍처 또는 마이크로서비스 아키텍처를 가질 수 있습니다. 소프트웨어의 모든 기능과 모듈은 단일 단위 또는 모놀리식 애플리케이션의 코드베이스에 포함됩니다. 이와 대조적으로 마이크로서비스 애플리케이션은 HTTP 프로토콜과 같은 인터페이스를 통해 서로 상호작용하는 수많은 작은 단위로 구성됩니다.
모놀리식 스타일의 주요 문제는 엔지니어가 기존 기반 위에 새로운 기능과 서비스를 추가함에 따라 시스템을 변경, 업데이트 및 확장하기가 더 어려워진다는 것입니다. 애플리케이션의 한 측면에 대한 변경은 다른 섹션에 해로운 영향을 미칠 수 있습니다. 모놀리스의 코드는 스케일링, 업데이트 및 변경을 거듭한 후에 점차적으로 너무 얽히고 이해하기 어려워져 완전한 시스템 재설계가 필요합니다.
이 문제는 마이크로서비스로 해결됩니다. 이 아키텍처 설계는 모놀리스를 구성 구성 요소로 나누고 각 구성 요소는 별도의 응용 프로그램으로 실행됩니다. 이러한 각 앱을 마이크로서비스라고 합니다. 그런 다음 이러한 고유한 마이크로서비스는 API를 사용하여 연결합니다. API로 연결된 이 마이크로서비스 모음은 함께 모여 더 큰 아키텍처 설계를 구축합니다. API는 마이크로서비스 아키텍처에 통합된 각 구성 요소 간의 연결 및 통신을 가능하게 합니다. API 생성에 대한 몇 가지 인기 있는 접근 방식은 GraphQL, RPC 및 REST 입니다.
RPC 란 무엇입니까?
RPC (원격 프로시저 호출)는 미리 정의된 형식을 사용하여 원격 서버에서 서비스를 실행하고 동일한 형식으로 응답을 받을 수 있도록 하는 웹 아키텍처입니다. 쿼리를 수행하는 서버의 스타일은 로컬 서버인지 원격 서버인지에 관계없이 RPC 디자인에서 고려되지 않습니다.
이미지 출처 itrelease.com/Author Junaid Rehman
RPC API 요청의 기본 기능은 REST API와 동일합니다. RPC API 요청은 상호 작용 지침과 상호 작용을 가능하게 하는 기술을 지정합니다. 나중에 사용자는 매개변수를 사용하여 이러한 함수를 호출합니다. URL의 요청 문자열에는 작업을 호출하는 데 사용되는 매개변수가 포함됩니다.
API 요청을 생성하기 위해 RPC 시스템은 클라이언트-서버 구조를 사용합니다. RPC 는 사용자가 요청한 정보를 해석하여 서버로 전송합니다. 서버 내의 내부 통신은 숨겨져 있는 동안 서버는 사용자에게 응답합니다. RPC 모델은 또한 사용자가 특정 방식으로 서비스를 요청할 수 있도록 합니다. RPC 는 분산 및 온프레미스 시나리오 모두에서 원격 프로시저 호출을 지원하는 이점이 있습니다.
REST 란 무엇입니까?
REST - Representational State Transfer - 사용자가 JSON 또는 XML 통신을 통해 백엔드 정보에 액세스할 수 있는 클라이언트-서버 아키텍처를 나타냅니다. API는 다음과 같은 경우 RESTful로 간주됩니다.
- 일관된 인터페이스를 가지고 있으며 API 클라이언트에 특정 앱 리소스를 제공합니다.
- 서버와 클라이언트는 개별적으로 독립적으로 작동합니다. 응용 프로그램의 구성 요소를 가리키는 URI만 클라이언트에 알려집니다.
- 무국적자입니다. 즉, 클라이언트만 상태 정보를 저장합니다. 서버는 클라이언트 쿼리에 대한 상태 데이터를 저장하지 않습니다.
- API에서 제공하는 애플리케이션 자산은 캐시 가능해야 합니다.
- 계층 구조를 가지고 있습니다.
하이퍼미디어 네트워크에서 데이터 전송을 허용하기 위해 여러 제한 사항에 의존하는 현대 건축 설계의 응용 프로그램입니다. RESTful 웹 API는 HTTP 프로토콜을 사용하여 서비스에 연결하기 위해 URL로 인코딩된 인수가 필요합니다. REST API는 상태 비저장, 확장 가능 및 신뢰할 수 있는 API를 만들기 위해 현대 웹 디자인에 광범위하게 채택되었습니다.
마이크로 서비스 시스템을 결합하는 각 구성 요소는 REST API가 공개적으로 액세스 가능하게 되면 사용자 또는 고객에게 자산으로 표시될 수 있습니다. 이 리소스는 HTTP GET, POST, PUT 및 DELETE 명령을 사용하여 쿼리할 수 있습니다.
REST 는 어떻게 작동합니까?
REST 는 API 요청에 지정된 서비스로 작업할 때 HTTP 프로토콜을 기본 통신 프로토콜로 사용합니다. 자원은 객체 지향 설계에서 객체와 비교할 수 있는 것입니다. RESTful 리소스에는 객체와 매우 유사한 작업과 속성이 있습니다. 일반적으로 REST 구현은 일반적으로 RESTful 작업에 대해 덜 생각하고 대신 리소스의 속성에 더 집중합니다. RESTful 솔루션은 속성을 사용하여 RESTful 리소스를 나타내는 솔루션입니다.
RESTful API에서 사용자는 URL(Uniform Resource Locator)에 쿼리를 제출하여 JSON, XML 또는 지원되는 모든 데이터 형식의 페이로드로 응답합니다. 이 페이로드는 사용자가 원하는 리소스를 나타냅니다. 일반적인 클라이언트 요청에는 다음이 포함됩니다.
- 리소스에서 처리할 항목을 지정하는 HTTP 메서드
- 리소스의 경로
- 쿼리에 대한 데이터가 있는 헤더
- 클라이언트별 메시지 페이로드
헤더의 Accept 필드에서 사용자는 수신할 수 있는 데이터 유형을 지정합니다. 응답 본문에 사용된 메시지 전달 형식을 식별하는 콘텐츠 유형 헤더는 쿼리를 만드는 사용자에게 전달하는 데이터 페이로드와 함께 API 서버에 의해 전송됩니다. API 호출의 결과 상태를 사용자에게 알려주는 응답 코드도 응답 본문에 포함됩니다.
g RPC 란 무엇입니까?
g RPC (Google 원격 프로시저 호출)는 RPC 설계의 하위 유형입니다. g RPC 는 마이크로서비스 아키텍처의 유연성과 속도를 보장하는 고성능 글로벌 오픈 소스 RPC 아키텍처입니다. 함수 호출은 다양한 코딩 언어를 사용하여 생성된 마이크로서비스에서 고객 상호 작용을 보장하기 위해 g RPC 에서 사용됩니다.
이 기술은 HTTP 2.0 표준을 사용하여 RPC API 요청을 구현하지만 서버나 API 프로그래머 모두 HTTP를 인식하지 못합니다. 결과적으로 RPC 원칙이 HTTP로 변환되는 방식에 대해 걱정할 이유가 없기 때문에 복잡성이 줄어듭니다.
Google 원격 프로시저 호출은 마이크로서비스 간의 데이터 전송 속도를 높이려고 합니다. 원격 반환 및 호출을 허용하기 위해 서비스를 식별하고 방법론을 설정하고 해당 변수를 지정하는 전략을 기반으로 합니다.
또한 IDL (인터페이스 설명 언어)을 사용하여 RPC API 패러다임을 지정하므로 원격 기능을 더 쉽게 식별할 수 있습니다. IDL 은 기본적으로 프로토콜 버퍼를 사용하여 서비스 인터페이스와 페이로드 메시지 형식을 정의합니다.
g RPC 는 어떻게 작동합니까?
HTTP/2 프로토콜, 스트리밍 및 프로토콜 버퍼 또는 protobufs 는 g RPC API에서 메시지를 전송하는 데 사용됩니다. protobuf라는 직렬화 표준을 사용하면 사용자 라이브러리를 자동으로 생성하고 마이크로서비스를 직접 구성할 수 있습니다. proto 파일에서 API 디자이너는 서버와 클라이언트 간에 전송되는 작업과 메시지를 설명합니다.
protoc 컴파일러는 파일을 로드하고 원격 서비스와 통신하기 위한 사용자 및 서버 소프트웨어를 만듭니다. XML 또는 JSON 형식과 비교하여 프로토콜 버퍼로 암호화된 메시지는 상당히 작기 때문에 CPU 이 적습니다.
또한 HTTP/2를 사용하는 g RPC API는 RPC 설계를 다양하게 개선합니다. 프로토콜은 패킷을 더 작은 이진 프레임 메시지로 분할하여 전송 가능하고 작게 만드는 이진 형식 계층을 추가합니다. 단일 채널 내에서 많은 호출을 실행하는 것은 양방향 통신 아키텍처를 사용하는 다중 동시 쿼리에 대한 HTTP/2의 지원으로 가능합니다.
HTTP/2 전송 프로토콜은 여러 동시 스트림을 지원하지만 g RPC API는 채널을 통해 이 기능을 확장합니다. 각 채널은 많은 동시 연결을 통해 동시에 실행되는 여러 스트림을 수용할 수 있습니다. 채널은 주어진 주소와 포트에서 API 서버에 연결하는 간단한 방법을 제공합니다. 클라이언트 스텁은 채널을 통해 만들 수도 있습니다.
g RPC 대 REST: 비교
Google은 기존 API 아키텍처 스타일의 일부 제한 사항을 처리하기 위해 RPC 변형으로 g RPC 를 만들었습니다. REST API와 관련된 몇 가지 문제를 해결하지만 g RPC API는 최신 기술이기 때문에 특정 문제에 직면합니다. REST API가 애플리케이션에 더 적합할 수 있는 많은 사용 사례가 있습니다. 둘 사이의 차이점을 알고 나면 이러한 API 중 소프트웨어에서 더 잘 작동할 수 있는 API를 결정할 수 있습니다.
HTTP 1.1 대 HTTP 2
REST API에서 사용하는 요청-회신 접근 방식은 주로 HTTP 1.1을 기반으로 합니다. 즉, 마이크로 서비스가 여러 클라이언트로부터 많은 쿼리를 받는 경우 모델이 모든 쿼리를 개별적으로 처리해야 하므로 전체 시스템이 다운됩니다. REST API는 HTTP 2에서 개발할 수 있지만 통신 아키텍처는 여전히 요청-응답이므로 양방향 호환성 및 스트리밍 상호 작용을 포함하여 HTTP 2의 이점을 완전히 활용할 수 없습니다.
g RPC API에는 이 문제가 발생하지 않습니다. 클라이언트 응답 연결 모델을 따르고 HTTP 2를 기반으로 합니다. g RPC 는 다양한 클라이언트의 많은 쿼리를 수락하고 스트리밍 정보를 통해 이러한 요청을 동시에 처리할 수 있습니다. 이러한 상황은 스트리밍 상호 작용과 양방향 통신을 허용합니다. 또한 g RPC 는 HTTP 1.1에서 생성된 것과 같은 단항 상호 작용을 지원합니다.
g RPC API는 다음을 관리할 수 있습니다.
- 단항 상호작용
클라이언트가 단일 요청을 했지만 그 대가로 하나의 응답만 제공되는 경우. - 서버 스트리밍
서버가 메시지 스트림으로 클라이언트 쿼리에 응답할 때마다 이를 서버 스트리밍이라고 합니다. 서버는 또한 모든 데이터를 제공한 후 절차를 마무리하기 위해 상태 메시지를 보냅니다. - 클라이언트 스트리밍
이것은 클라이언트가 일련의 메시지를 전달하고 서버가 단일 메시지로 응답할 때 발생합니다. - 양방향 스트리밍
이렇게 하면 서버와 클라이언트 채널이 서로 독립적이기 때문에 양방향으로 데이터를 전송할 수 있습니다.
브라우저 지원
대부분의 웹 API 상호 작용은 온라인에서 발생하기 때문에 브라우저 지원은 g RPC 대 REST 논쟁에서 핵심 고려 사항입니다. 브라우저 지원은 g RPC 에 비해 REST API의 주요 이점 중 하나일 수 있습니다. 모든 브라우저는 완전한 REST API 기능과 브라우저 지원을 제공합니다. 그러나 브라우저에서 g RPC 의 기능은 여전히 상대적으로 제한적입니다. 불행히도 HTTP 1.1과 HTTP 2 간의 전환에는 gRPC-web과 프록시 레이어가 필요합니다. 결과적으로 g RPC API는 특정 조직의 백엔드 정보 및 기능에 사용되는 API 애플리케이션과 같이 내부 또는 개인 시스템에 주로 활용되는 경향이 있습니다.
다중화된 스트림은 HTTP/2 프로토콜과 함께 사용됩니다. 결과적으로 수많은 고객이 각각에 대해 새 TCP 세션을 열 필요 없이 쿼리를 병렬로 보낼 수 있습니다. 또한 서버는 기존 링크를 사용하여 클라이언트에 메시지를 전달할 수 있습니다.
표현 상태 전송 모델은 HTTP 1.1을 통합하기 때문에 광범위한 브라우저 지원을 제공합니다. REST 가 활성화된 HTTP 1.1은 각 쿼리에 대해 TCP 핸드셰이킹 방식을 사용합니다. REST API는 핸드셰이크에 시간이 걸리기 때문에 결과적으로 지연 문제가 자주 발생합니다.
페이로드 데이터 구조
g RPC 대 REST 를 보면서 페이로드 데이터 구조를 보고 있다면 g RPC API는 의도적으로 프로토콜 버퍼를 사용하여 페이로드 데이터를 직렬화합니다. 이 방법은 메시지를 더 작게 만들고 고도로 압축된 구조를 허용하므로 더 가볍습니다. 프로토콜 버퍼는 바이너리 형식입니다. 따라서 데이터 교환을 위해 정보를 직렬화 및 역직렬화합니다. Protobuf는 많이 작성된 메시지를 클라이언트 및 서버 프로그래밍 언어로 자동 번역할 수 있습니다.
그러나 REST 는 대부분 JSON 또는 XML 형식을 사용하여 정보를 전달하고 받습니다. JSON 은 정확한 구조를 요구하지 않지만 정확한 구조를 고수하지 않고 동적 데이터를 전달할 수 있는 적응성과 용량 때문에 가장 널리 사용되는 형식입니다. Protobuf가 아직 따라할 수 없는 JSON의 가독성 품질은 또 다른 중요한 이점입니다.
그러나 JSON 은 데이터 전송을 포함하면 빠르거나 가볍지 않습니다. 이는 JSON 이 REST 를 사용할 때 서버와 클라이언트 측 모두에서 사용되는 프로그래밍 언어로 직렬화되고 번역되어야 한다는 요구 사항 때문입니다. 이는 데이터 전송 프로세스의 추가 단계로, 효율성을 저해하고 실수 가능성을 높일 수 있습니다.
코드 생성
엔지니어는 API 쿼리를 위한 코드 생성 을 위해 Postman과 같은 타사 도구를 사용해야 하며 g RPC 와 달리 REST API에는 기본 제공 코드 생성 기능이 없습니다. 이와는 대조적으로 g RPC 는 많은 프로그래밍 언어를 지원하는 protoc 컴파일러로 인해 기본 코드 생성 기능을 제공합니다. 코드 생성은 여러 플랫폼 및 언어에서 생성된 수많은 서비스를 결합하는 마이크로서비스에 특히 유리합니다. 전반적으로 내장된 코드 생성 기능을 통해 소프트웨어 개발 키트(SDK)를 보다 쉽게 구성할 수 있습니다.
반면 REST API는 기본 코드 생성 기능을 제공하지 않습니다. 여러 언어로 API 호출에 대한 코드 생성을 생성하려면 타사 프로그램을 사용해야 합니다. 번거롭지는 않지만 g RPC 는 코드 생성을 위해 다른 서비스에 의존하지 않는다는 점에 유의하는 것이 중요합니다.
REST API를 사용하는 경우
g RPC 와 REST 를 비교할 때 마이크로 서비스에 구축된 인프라를 통합하기 위해 가장 광범위하게 사용되고 선호되는 API는 REST API입니다. REST API는 내부 네트워크를 생성하는지 아니면 자산을 전 세계에 공개하는 개방형 플랫폼을 생성하는지에 관계없이 매우 오랫동안 앱 연결을 위한 기본 옵션으로 계속 사용될 것입니다. REST API는 빠른 반복 및 HTTP 프로토콜 표준이 필요한 시스템에도 적합합니다.
REST API는 타사 기술이 보편적으로 지원하기 때문에 웹 서비스 개발, 마이크로서비스 및 앱 인터페이스를 위한 첫 번째 선택이 될 수 있습니다. g RPC 와 달리 광범위한 브라우저 지원을 제공하며 개인 시스템에 국한되지 않습니다. 이것은 REST API를 많은 상황에서 매우 유용하게 만들 수 있습니다.
또한 인터넷에서 사용할 수 있는 광범위한 API 문서가 있으므로 REST 를 배우는 것이 더 쉽습니다. 이 간단한 학습 곡선은 시간이 부족한 경우 매우 중요합니다. 조사하고 배우는 데 많은 시간을 절약하고 즉시 구현을 시작할 수 있습니다. RESTful API는 또한 애플리케이션에 더 쉽게 통합할 수 있습니다. 또한 더 나은 확장성을 제공합니다. 곧 애플리케이션을 확장하고 싶다면 REST API를 사용하는 것이 더 나을 수 있습니다. 상태 및 기밀성이 부족하면 특정 응용 프로그램에서 대표 상태 이전에 문제가 발생할 수 있습니다. 애플리케이션에 지불 옵션이 있는 경우 g RPC 가 더 나은 옵션일 수 있습니다.
g RPC API를 사용하는 경우
g RPC 대 REST 둘 다에서 대부분의 타사 도구는 여전히 g RPC 규정 준수를 위한 기본 제공 기능을 제공하지 않습니다. 결과적으로 g RPC API는 외부 사용자가 액세스할 수 없는 내부 시스템 또는 구조를 만드는 데 주로 사용됩니다. 이러한 자격을 염두에 두고 다음 상황에서 g RPC API를 사용할 수 있습니다.
- 마이크로서비스 연결
g RPC API는 짧은 대기 시간과 빠른 대역폭 통신으로 인해 메시지 전달의 효율성이 중요한 가벼운 마이크로서비스로 구성된 아키텍처를 연결하는 데 특히 유용합니다.
- 다국어 시스템
g RPC 는 광범위한 프로그래밍 언어에 대한 기본 코드 생성 기능 덕분에 다중 언어 컨텍스트에서 통신을 처리하는 데 탁월합니다.
- 실시간 스트리밍
실시간 통신이 필요한 경우 양방향 스트리밍을 처리하는 gRPC 기능 덕분에 시스템은 단항 클라이언트 응답 상호 작용을 기다릴 필요 없이 실시간으로 데이터를 송수신할 수 있습니다.
- 저전력 및 저대역폭 네트워크
이러한 네트워크는 경량 통신, 향상된 효율성 및 신속성을 제공하기 때문에 직렬화된 Protobuf 세션을 사용하는 gRPC의 이점을 누릴 수 있습니다. 예를 들어, g RPC API에서 이익을 얻을 수 있는 네트워크는 사물 인터넷입니다.
AppMaster 는 어떻게 도움이 되나요?
프로그래밍은 최근 수십 년 동안 개발자의 작업을 더 쉽게 만드는 새로운 기술과 프레임워크로 인해 많이 변경되었습니다. No-code 생성은 이를 다음 단계로 끌어 올립니다. 사람들은 가파른 학습 곡선을 거칠 필요가 없으며 AppMaster 와 같은 no-code 플랫폼을 사용하여 애플리케이션을 더 빠르게 개발할 수 있습니다.
AppMaster 를 사용하면 애플리케이션의 특정 요구 사항에 따라 소스 코드를 처음부터 생성할 수 있습니다. 생성된 코드는 귀하의 소유이며 필요에 따라 수정할 수 있습니다. AppMaster 를 사용하여 애플리케이션에 필요한 다양한 모듈을 생성할 수 있습니다. 이는 전체 개발 팀이 동일한 작업을 수행하도록 하는 것보다 훨씬 저렴하고 시간이 많이 소요됩니다.
개발자는 AppMaster의 no-code 생성 플랫폼을 사용하여 g RPC 프로토콜을 사용하여 백엔드 마이크로서비스 아키텍처 간에 쿼리를 보낼 수 있습니다. 우리는 g RPC 지원을 증가시키기 위해 내년에 g RPC 웹 서비스 개발과 g RPC 모바일 앱 모두에 API를 추가할 것입니다.
결론
Representational state transfer는 과거에 API 개발과 관련하여 가장 많이 사용되는 접근 방식이었습니다. 그러나 g RPC 대 REST 사이에서 g RPC API가 서서히 대중화되고 있습니다. 눈에 띄는 다양한 기능에도 불구하고 브라우저 지원 및 API 문서 부족과 같은 일부 문제로 인해 모든 곳에서 사용하기 어렵습니다. 그러나 기술 발전과 커뮤니티 성장으로 g RPC 가 오늘날의 도전을 극복할 수 있기를 바랍니다.
마지막으로 REST 또는 g RPC 또는 GraphQL 또는 SOAP 와 같은 다른 API 방법론 중에서 선택하는 것은 프로젝트의 특정 요구 사항에 따라 다릅니다. 일부 애플리케이션에는 g RPC 가 제공하는 이점이 필요할 수 있지만 다른 애플리케이션에는 REST 가 제공하는 기본 기능이 필요할 수 있습니다. 애플리케이션의 기능과 사용 사례를 평가하여 이 두 가지 기술 중에서 선택해야 합니다.
