API프로토콜(REST, gRPC, GraphQL)에 대해

API는 왜 중요할까?

추상과 구체를 분리하여 지금 당장 중요하지 않은 것들에 종속되지 않으면서 기능을 사용할 수 있다.

REST API

• 특징
  • 리소스 중심으로 API가 구성된다.
  • HTTP Method를 통해 Action정의
  • JSON, XML등을 사용한다.
• 장점
  • 학습과 사용이 쉽고, 자유도가 높아 원하는 대로 사용이 가능하다.
• 단점
  • API가 자주 바뀌게 된다. -> Type, field내용 등의 변경이 잦을 수 있음.
  • 버저닝(Versioning)
  • 명세 찾기가 어려움
  • 죽은 문서
  • 개발 종속성

인터페이스 정의 언어(Interface Description Language : IDL)

소프트웨어 컴포넌트의 인터페이스를 묘사하긴 위한 명세 언어

IDL은 어느 한 언어에 국한되지 않는 언어 중립적은 방법으로 인터페이스를 표현함으로써, 같은 언어를 사용하지 않는 소프트웨어 컴포넌트 사이의 통신을 가능하게 한다.

OpenAPI

보통 이 IDL을 사용할 때 처음으로 검토하는 친구일 것이다.
-> Swagger API

• 버져닝이 가능하다.
• RESTful web service의 표현이 가능하다.
• API우선 접근이 가능하다.
  • 보통 서버 개발이 완료된 후에 프론트 개발이 진행되고는 하는데 이거 서버 개발에 따라서 막 규격이 바뀌면 안되니까, API부터 우선 만들어두자!! 라는 느낌이라 생각하면 된다.

그래서 이 Open API에 대해서

• 장점
  • API우선 접근 방식 적용
    • 특성 서버에 대한 의존성이 감소한다!
  • Machine-readable interface
    • 컴퓨터가 이해할 수 있는 interface이기 때문에 일반 문서와 달리 바로 컴퓨터에서 활용 가능
  • 클라이언트 라이브러리 빌드 불필요
  • 버져닝이 용이하다.
• 단점
  • REST API의 연장성이다.
    • 그니까 이 OpenAPI자체가 REST용임
  • 가독성이 별로임
  • 버젼 규칙의 관리가 필요하다.
    • semantic versioning

gRPC

구글에서 최초로 개발한 오픈소스 원격 프로시저 호출(RPC) 시스템

약간 어떤 내용을 호출할 때에 네트워크 호출이 아니라, function call 형태로 호출하도록 하는 느낌이다.
JSON이 아니라, gRPC형태로 데이터를 encoding/decoding 가능

• 기본적으로 하위 호환을 지원하는 형태로 API를 변경한다.
  • 특정 내용이 deprecate되면 그냥 reserve하는 느낌으로, 하위버전 클라이언트에서 상위버젼 서버를 사용했을 때에 딱히 문제가 발생하지 않도록 해준다!

그거 어떻게 하는건데.

• gRPC는 HTTP/2를 사용해서 동작한다.
  • 다만 웹에서 강제로 HTTP/2를 사용하도록 강제하는게 불가능하므로 현재 브라우저에서는 HTTP/2 gRPC 스펙을 구현할 수는 없다.

클라이언트에서 이걸 해결한 방법

Client gRPC-Web을 사용함

• gRPC-Web Proxy를 통해 해결하였다.
  
• 요렇게 Sidecal Proxy에서 웹브라우저의 요청을 gRPC요청으로 변경해준다.

이것도 뭔가 여러 방식을 사용해서 진행할 수 있는데

• gRPC-Web
  • protoc 컴파일러를 이용해서 빌드하면 js파일이 생성되고 이거를 그냥 로드해서 사용하는 방식
• gRPC HTTP/JSON. Transcoding
  • 실제로 REST API로 변경하는 방식
    • 그래서 이것도 protobuf 컴파일을 이용해서 OpenAPI로 바로 변경 가능하다.

gRPC 장점

• 장점
  • 속도가 빠르다.
    • 데이터 encoding/decoding이 빠름
    • HTTP/2.0위에서 동작함
  • API우선접근 가능
  • 클라이언트/서버 스트리밍 지원
• 단점
  • 서버 환경 구성 및 운영 코스트
    • 사이드카 프록시의 필요성

GraphQL

API를 위한 쿼리 언어

서버 쪽에서 스키마를 작성 하고, 클라이언트 측에서 원하는 데이터를 불러오기 위한 쿼링을 진행해주는 느낌이다.
그니까 원하는 것만을 요청하고 받아오는 것이다.
이 덕분에 GraphQL에서는 버저닝 없이 API를 사용할 수 있다.

GraphQL은 연결된 리소스들을 하나의 요청으로 함께 받을 수 있다.

• 장점
  • 하나의 네트워크 요청으로 여러 리소스의 로드가 가능하다.
  • 필요한 정보만 선택해서 로드 가능
  • 버져닝 불필요
• 단점
  • 클라이언트쪽 쿼리 구성으로 인해 코드가 많아짐
  • 생각보다 하나의 API에서 여러 서비스를 호출할 일이 없다..?

정리