▲

GN⁺: gRPC, OpenAPI 및 REST 이해와 API 설계에서의 활용 시기 (2020)

 (cloud.google.com)
1P by neo 1달전 | ★ favorite | 댓글 1개

API 관리

gRPC와 REST: API 설계에서 gRPC, OpenAPI, REST의 이해와 사용 시점

  • API 설계 모델: API 설계에는 주로 RPC와 REST 두 가지 모델이 사용됨. 대부분의 현대 API는 HTTP 프로토콜을 기반으로 구현됨.
  • gRPC: HTTP 2.0을 전송 프로토콜로 사용하는 RPC API 구현 기술. Google 등에서 RPC와 HTTP의 아이디어를 결합한 API를 많이 사용함.
  • HTTP의 세 가지 주요 사용 방식:
    1. REST: 클라이언트가 서버에서 제공하는 URL을 그대로 사용하며, URL 형식을 이해할 필요가 없음.
    2. gRPC: HTTP/2를 사용하지만, HTTP는 API 설계자에게 노출되지 않음.
    3. OpenAPI: 클라이언트가 URL 경로 템플릿을 사용하여 API를 호출함.

REST

  • 특징: 클라이언트가 URL 형식을 이해할 필요가 없으며, URL은 API 사양의 일부가 아님.
  • 장점: 안정성, 일관성, 보편성 등 웹의 장점을 가짐. 엔티티 지향 모델이 더 간단하고 이해하기 쉬움.

gRPC

  • 특징: HTTP/2를 사용하지만, HTTP의 세부 사항은 숨겨짐. 클라이언트는 절차를 호출하고 매개변수를 전달하여 API를 사용함.
  • 장점: 클라이언트 측 프로그래밍 라이브러리를 쉽게 생성할 수 있으며, 성능이 좋음.

OpenAPI

  • 특징: URL 경로 템플릿을 사용하여 API를 호출하며, 클라이언트가 URL 형식을 이해해야 함.
  • 장점: 표준 HTTP 기술만으로 API에 접근 가능. 클라이언트 측 프로그래밍 라이브러리를 생성할 수 있음.

gRPC와 OpenAPI의 비교

  • 유사점: 둘 다 RPC 인터페이스 정의 언어(IDL)로 사용 가능.
  • 차이점: gRPC는 HTTP 세부 사항을 숨기고, OpenAPI는 HTTP 세부 사항을 노출함.

REST의 장점

  • 엔티티 지향 모델: 더 간단하고 이해하기 쉬우며, 시간이 지나도 안정적임.

OpenAPI 사용 방법

  • 경로 정의: 경로와 HTTP 메서드를 사용하여 API를 정의함.

OpenAPI의 장단점

  • 장점: RPC 모델과 유사하여 프로그래머에게 친숙함. HTTP 요청으로 매핑할 수 있음.
  • 단점: HTTP 세부 사항을 설계하는 데 많은 노력이 필요함.

gRPC의 장점

  • 간단한 구현: 서버 측 구현이 간단하며, 클라이언트 측 라이브러리를 쉽게 생성할 수 있음.
  • 성능: 이진 페이로드를 사용하여 효율적임.

gRPC의 단점

  • 특수 소프트웨어 필요: 클라이언트와 서버 모두 특수 소프트웨어가 필요함.
  • 프록시 기능 제한: HTTP API와 달리 프록시에서 기능을 확장하거나 수정하기 어려움.

결론

  • API 설계 선택: REST, OpenAPI, gRPC 각각의 장단점을 고려하여 선택해야 함.
  • gRPC 사용 시 고려 사항: 클라이언트가 gRPC 기술을 채택하지 않아도 되는 경우, 내부 API인 경우 유리함.
▲
neo 1달전  [-]
Hacker News 의견

  • gRPC를 배우지 말았어야 했다는 후회가 있음. 디버깅과 설정 조정에 많은 시간이 소요되었음

    • gRPC는 내부를 숨긴다고 하지만, 실제로는 많은 디버깅과 설정 조정이 필요함
    • Maven 플러그인, HTTP2와의 호환성 문제, 방화벽 문제 등으로 많은 시간을 낭비했음
    • 문서가 부실하고, 오류 메시지를 관찰 가능하게 만드는 데 어려움이 있었음

  • 오랫동안 API를 구축해왔으며, gRPC와 HTTP/REST를 사용해왔음

    • OpenAPI와 REST의 차이를 구분하는 것이 이상하다고 생각함
    • OpenAPI는 HTTP API의 동작을 문서화하는 방법이며, RESTful API를 표현할 수 있음
    • gRPC는 프로토콜 버퍼를 주고받는 RPC 메커니즘임
    • gRPC는 효율적이지만, HTTP 라이브러리만큼 강력하지 않음

  • FAANG에서 일한 경험이 있으며, 내부 서비스 라우팅에 gRPC가 유용하다고 생각함

    • RPC 프로토콜은 대규모 및 고속으로 작업을 가능하게 함
    • 그러나 고객이나 웹을 대상으로 하는 경우에는 gRPC를 사용하지 않을 것임

  • 양방향 스트리밍을 하지 않는 한, gRPC는 시간 낭비라고 생각함

    • 다양한 언어로 구현된 서비스 간의 RPC 호출을 할 때 많은 미들웨어가 필요함

  • gRPC를 사용한 프로젝트에서 성능을 이유로 도입했으나, JSON API로 전환했음

    • gRPC에 대한 경험이 부족했고, 프로젝트는 여러 문제로 인해 실패했음

  • connectrpc를 사용하면서 gRPC의 문제점을 해결하고 있음

    • buf.build를 통해 3rd party proto 파일을 쉽게 가져올 수 있음
    • SDK 자동 생성 기능이 매우 유용함

  • gRPC는 REST보다 개발 경험이 나쁘다고 생각함

    • 추가적인 도구가 필요하고, 생성된 클라이언트 코드가 복잡함

  • REST API는 초기 URI와 표준화된 미디어 타입만 알면 된다고 Roy Fielding이 언급함

  • 데이터 센터 내에서 gRPC 사용을 좋아하지 않음

    • 성능이 높지 않고, 오픈 소스 클라이언트의 품질이 낮음
    • 웹 기반 API에서는 JSON의 가독성을 선호하지만, 타입 불일치 문제가 있음

  • gRPC는 Google 외부에서는 접근하기 어렵다고 느꼈음

    • gRPC JS 클라이언트가 무겁고 불투명함
    • REST의 단순함에 비해 실행이 잘못되었다고 생각함
답변달기