좋은 API 디자인하기 - RPC API

RPC

RPC는 Remote Procedure Call의 약자로 원격 장비에 있는 함수나 메서드를 실행하는 방법이다.

• 인터페이스 기술(SOAP, Thrift, Protocol Buffer)이 필요하며, 이 인터페이스 정의를 통해 서로 다른 기술 스택에 대한 클라이언트 및 서버 스텁(stub)을 보다 쉽게 생성할 수 있다.
• HTTP를 통해 RPC 호출을 보낼 수 있고 원하는 경우 좀 더 가벼운 TCP나 UDP 소켓도 사용할 수 있다.
• HTTP를 사용하지 않기 때문에 대기 시간이 짧아지고, JSON이나 XML이 아닌 바이너리 메시지 형식을 구현해 메시지 크기가 작기 때문에 속도가 빠르고 성능이 좋다.

RPC 메시지 프레임워크

Thrift
페이스북에서 만들어졌고 현재는 아파치 소프트웨어 재단에서 관리하고 있다.

<목표 3가지>

• 단순함 : 직관적이고 친숙하며 불필요한 의존성이 없도록 작성한다.
• 투명성 : 다른 언어에서 일반적인 관용구(idiom)는 그대로 준수한다.
• 일관성 : 간결함, 개별 언어를 위한 기능은 핵심 라이브러리가 아닌 확장 기능에 추가한다.

<Thrift의 서비스 정의>

struct User {
	1: string name,
    2: i32 id,
    3: string email
}

struct Error {
	1: i32 code,
    2: string detail
}

struct Users {
	Error createUser(1: User user)
}

Protocol Buffer

• 구글에서 만들었으며 gRPC에서 구조화된 데이터 직렬화 및 역직렬화를 위해 사용한다.
• 생성자(C로 작성)RK 10개 이상의 언어에 대해 클라이언트 및 서버 스텁을 읽고 생성할 수 있는 DSL을 제공하는 방식을 취한다.
• 플러그형(pluggable) 아키텍처이므로 RPC를 포함한 모든 종류의 엔드포인트를 생성하기 위한 플러그인을 작성할 수 있다.

<Protocol Buffer의 서비스 정의>

service Users {
	rpc CreateUser (User) returns (Error) {}
}

message User {
	required string name = 1;
    required int32 id = 2;
    optional string email = 3;
}

message Error {
	optional code int32 = 1
    optional detail string = 2
}

RPC API 버전 관리 형식

RPC의 이름 지정

• RPC를 사용하면, 사용자 컬렉션 예제에서 했던 것처럼 HTTP 동사를 사용해 API의 의도를 나타내는 고급 기능을 사용할 수 없다.
• RPC API에서는 HTTP API의 동사(GET, POST 등등)을 사용할 수 없기 때문에, Go 코드 내에서 메서드를 작성하는 것과 같은 방식을 사용해야 한다.

# HTTP 메서드
GET /v1/users

# RPC 메서드
Users.v1.Users
GET /v1/users/123434

# HTTP 메서드
DELETE /v1/users/123123

#RPC 메서드
Users.v1.DeleteUser