Programing

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

lottogame 2020. 9. 14. 21:33
반응형

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


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

여기에 이미지 설명 입력

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


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

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

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

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

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

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

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


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

If you need an RPC-style service, sure, gRPC is great. If you want to live on the web, or you want all the benefits that come with a RESTful style service, then build an RESTful style service. And if it's too slow to serialize/deserialize data in JSON format in your restful service, it's perfectly OK to use protobuf or whatever.

If gRPC is a version 2 of anything, it's a version 2 of SOAP. One that isn't terrible, like SOAP.

And, no, you can't just "call any function" in your GET request, and have a RESTful service.

One last thing: if you are gonna use protobufs over a RESTful service, please do it right, using the content type headers, etc. With that, you can easily support both JSON AND protobuf.

Stepping down from my SOAP box now.. ;)


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

참고 URL : https://stackoverflow.com/questions/43682366/how-is-grpc-different-from-rest

반응형