GRPC는 REST와 어떻게 다릅니 까?


98

GRPC에 대한 설명을 읽고 있는데이 다이어그램이 흥미 롭습니다.

여기에 이미지 설명 입력

전송 계층은 어떻게 작동합니까? 네트워크를 통해 ... RPC라고하는 이유는 무엇입니까? 더 중요한 것은 이것이 서비스 계층 (http 요청을 만드는 메서드가있는 클라이언트의 클래스)을위한 API를 구현하는 REST와 어떻게 다릅니 까?


20
«네트워크에있는 경우 ... RPC라고하는 이유는 무엇입니까?»— RPC는 원격 프로 시저 호출이고 '원격'은 완전히 '다른 호스트에서'를 의미 할 수 있기 때문입니다.
weirdan apr

답변:


104

전송 계층은 TCP / IP 위에 HTTP / 2를 사용하여 작동합니다. 이를 통해 클라이언트에서 서버로의 단일 연결을 활용할 수있는 짧은 대기 시간 (더 빠른) 연결이 가능합니다 (연결을보다 효율적으로 사용하고 서버 리소스를보다 효율적으로 사용할 수 있음).

HTTP / 2는 양방향 연결 및 비동기 연결도 지원합니다. 따라서 서버가 클라이언트와 효율적으로 접촉하여 메시지 (비동기 응답 / 알림 등)를 보낼 수 있습니다.

REST와 gRPC 모두 클라이언트 / 서버 스텁을 생성 할 수 있지만 (REST 용 swagger와 같은 것을 사용) REST에는 제한된 기본 '함수'호출 (또는 동사) 집합이 있습니다.

+ ----------- + ---------------- +
| HTTP 동사 | CRUD |
+ ----------- + ---------------- +
| GET | 읽기 |
| PUT | 업데이트 / 교체 |
| 패치 | 업데이트 / 수정 |
| 삭제 | 삭제 |
+ ----------- + ---------------- +

gRPC는 동기 / 비동기, 단방향 / 양방향 (스트림) 등 모든 종류의 함수 호출을 정의 할 수 있습니다.

gRPC를 사용하여 클라이언트는 로컬 메서드를 호출합니다. 프로그래머에게는 로컬 호출을하는 것처럼 보이지만 기본 계층 (자동 생성 된 클라이언트 스텁)이 호출을 서버로 보냅니다. 서버에서는 메서드가 로컬로 호출 된 것처럼 보입니다.

gRPC는 모든 기본 배관을 처리하고 프로그래밍 패러다임을 단순화합니다. 그러나 일부 전용 REST 순수 주의자에게는 이것이 지나치게 복잡해 보일 수 있습니다. YMMV


2
따라서 간단한 질문 : REST에서는 모든 종류의 함수를 호출 할 수도 있습니다. 예를 들어 Rails에서는 RESTful이 아닌 엔드 포인트에 GET 요청을 보내고 리소스를 얻는 것 외에 다른 작업을 수행 할 수 있습니다. RESTful이 아닌 엔드 포인트에서 실제로 모든 기능을 시작할 수 있습니다. 로컬 메서드를 호출하는 것처럼 보이지만 실제로 내부적으로는 엔드 포인트에 대한 http 호출을 만드는 서비스를 REST에서 만들 수도 있습니다. 따라서 차이점은 그다지 크지 않습니다. 적어도 전송 계층에서는 그렇습니다. 아니면 그들은?
Jwan622

2
REST / RESTful은 HTTP를 통해 실행되고 gRPC는 HTTP / 2 (예 : WebSocket)를 통해 실행됩니다. Swagger의 코드 생성기를 사용하면 REST 용 클라이언트 및 서버 스텁을 생성 할 수 있으며 gRPC는 proto 파일을 사용하여 해당 스텁을 생성합니다 (이전 WSDL / SOAP 접근 방식과 다르지 않음). proto 파일은 유형을 정의하므로 생성 된 클라이언트 / 서버 스텁은 유형에 안전합니다. 휴대 기기에서 gRPC 연결은 모바일 앱의 다른 동시 연결과 동일한 기본 HTTP / 2 소켓을 공유 할 수 있으므로 효율적입니다.
mmccabe

다음은 gRPC에 대한 멋진 소개입니다. medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b 다음은 gRPC 데모입니다. github.com/mmcc007/go
mmccabe

1
Jwan622 및 mmccabe : Superglue 2.1 라이브러리를 사용하여 사과와 오렌지로 집을 지을 수 있습니다. 어느 시점에서 우리는 작업에 적합한 도구를 선택해야하며 항상 소프트웨어 시스템의 복잡성을 최소화하려고 노력해야합니다. 코드를 제거하여 항상 성능 최적화이라는 것을 잊지)
마틴 앤더슨

4
내 관점에서 RESTful API와 같은 것은 항상 오래된 프로토콜을 따라가는 "핵"이었습니다. 현대 언어에 더 적합한 스택을 사용할 수 있고 클라이언트가 특별히 어떤 언어를 사용하고 있는지에 대해 여전히 불가지론하고 성능을 극적으로 향상시킬 수있는 무언가가 등장한다면, 나는 가장 먼저 시류에 뛰어들 것입니다!
Martin Andersson

42

REST에는 JSON 또는 HTTP / 1.1이 필요하지 않습니다.

HTTP / 2를 통해 protobuf 메시지 (또는 기타)를 전송하는 RESTful 서비스를 간단하게 구축 할 수 있습니다.

HTTP / 2를 통해 JSON을 전송하는 RESTful 서비스를 빌드 할 수 있습니다.

HTTP / 1.1을 통해 protobuf 메시지를 보내는 RESTful 서비스를 빌드 할 수 있습니다.

RESTful 서비스는 HTTP / xx의 "해킹"이 아닙니다. HTTP의 모든 버전을 성공적으로 만든 기본 아키텍처 원칙을 따르는 서비스입니다 (예 : GET 요청의 캐시 기능 및 PUT 요청의 재생 가능성).

gRPC, SOAP 등 al은 해킹과 비슷합니다. HTTP를 통해 RPC 스타일 서비스를 터널링하고 방화벽 및 미들 박스 제한을 우회하기 위해 HTTP 위에 해킹하는 것입니다. 그것은 반드시 나쁜 것은 아닙니다. 때로는 REST 대신 RPC 스타일의 서비스를 원할 수 있으며, 우리는 미들 박스를 교체하기 어려운 세상에 살고 있어야합니다.

REST의 실제 정의를 읽을 시간이없는 경우 : https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

항상 TLDR이 있습니다. wikipedia의 버전 :

https://en.wikipedia.org/wiki/Representational_state_transfer

RPC 스타일 서비스가 필요한 경우 gRPC가 좋습니다. 웹에서 살기를 원하거나 RESTful 스타일 서비스와 함께 제공되는 모든 이점을 원한다면 RESTful 스타일 서비스를 빌드하십시오. 편안한 서비스에서 JSON 형식의 데이터를 직렬화 / 역 직렬화하는 것이 너무 느리다면 protobuf 등을 사용해도 좋습니다.

gRPC가 버전 2이면 SOAP 버전 2입니다. SOAP처럼 끔찍하지 않은 것.

그리고 아니요, GET 요청에서 "어떤 함수도 호출"하고 RESTful 서비스를 가질 수 없습니다.

마지막으로, RESTful 서비스를 통해 protobuf를 사용하려면 콘텐츠 유형 헤더 등을 사용하여 올바르게 수행하십시오.이를 통해 JSON과 protobuf를 모두 쉽게 지원할 수 있습니다.

지금 내 SOAP 상자에서 내리는 중 ..;)


gRPC를 사용하여 RESTful 서비스를 만들 수 없다는 것을 암시하고 있습니까?
Kevin S

1
Fielding의 논문을 인용 한 RTFM은 과도했지만 그렇지 않으면 큰 반응이었습니다.
rmharrison

4

REST에 비해 gRPC의 가장 큰 장점은 할아버지 HTTP 1.1보다 HTTP / 2를 지원한다는 것입니다. 그렇다면 HTTP 1.1에 비해 HTTP / 2의 가장 큰 장점은 'HTTP / 2를 통해 서버가 콘텐츠를 "푸시"할 수 있다는 것입니다 ...


1
서버 푸시에는 HTTP / 2가 필요하지 않습니다.
Robin Green

좀 더 구체적으로 말씀해 주시겠습니까? 이것은 HTTP에 대해 / 2 서버 푸시 이야기 위키입니다 : en.wikipedia.org/wiki/HTTP/2_Server_Push
데니스 왕

2
죄송합니다. HTTP 2 서버 푸시가 아니라 응답 스트리밍을 의미했습니다. 예를 들어 유서 깊은 긴 폴링 또는 웹 소켓과 같은 스트리밍 응답을 수행하는 다른 방법이 있습니다.
Robin Green

1
푸시 / 2 "HTTP / 2 푸시 및 gRPC 클라이언트 무시"푸시 ". 그래서 gRPC의 장점은 HTTP로부터 상속 / 2는 포함하지 않아야"HTTP gRPC 서버는 "전송하지 않습니다.
user675693
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.