RPC와 REST의 차이점은 무엇인가요?
원격 프로시저 호출(RPC)과 REST는 API 설계의 2가지 아키텍처 스타일입니다. API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다. 소프트웨어 개발자는 이전에 개발된 구성 요소나 서드 파티 구성 요소를 사용하여 함수를 실행하므로 처음부터 모든 것을 작성할 필요가 없습니다. RPC API를 사용하면 개발자가 외부 서버의 원격 함수를 마치 해당 소프트웨어 로컬에 있는 것처럼 직접적으로 호출할 수 있습니다. 예를 들어 다른 채팅 애플리케이션에서 메시징 함수를 원격으로 직접 호출하여 해당 애플리케이션에 채팅 기능을 추가할 수 있습니다. 반면 REST API를 사용하면 원격 서버에서 특정 데이터 작업을 수행할 수 있습니다. 예를 들어 애플리케이션은 REST API를 사용하여 원격 서버에 직원 데이터를 삽입하거나 수정할 수 있습니다.
RPC와 REST의 유사점은 무엇인가요?
원격 프로시저 호출(RPC)과 REST는 둘 다 API를 설계하는 방법입니다. API는 현대적 웹 설계 및 기타 분산 시스템에서 필수적인 요소입니다. API를 사용하면 2개의 개별 분산 애플리케이션 또는 서비스가 상대의 애플리케이션 또는 서비스의 내부 작동 방식을 몰라도 통신할 수 있습니다. 이 두 애플리케이션 또는 서비스는 소규모 데이터 교환을 제외하고는 서로 거의 하는 일이 없을 수 있습니다.
API는 프로그램의 백엔드(로직 구성 요소)에서 프로그램의 프런트엔드(디스플레이 구성 요소)와 통신하기 위한 일반적인 메커니즘이기도 합니다. 긴밀하게 결합된 통합 대신 API를 사용하여 웹 페이지와 웹 애플리케이션을 설계하면 코드를 다시 작성하지 않고도 규모를 조정하고 변경할 수 있습니다.
다음으로 RPC와 REST API 간의 다른 유사점에 대해 살펴보겠습니다.
추상화
API의 주요 목표는 네트워크 통신이지만 하위 수준 통신 자체는 API 개발자와 별개로 추상화됩니다. 따라서 개발자가 기술적 구현보다 기능에 집중할 수 있습니다.
통신
REST와 RPC 모두 HTTP를 기본 프로토콜로 사용합니다. RPC와 REST에서 가장 많이 사용되는 메시지 형식은 JSON과 XML입니다. JSON은 가독성과 유연성 때문에 선호됩니다.
언어 간 호환성
개발자는 원하는 언어로 RESTful 또는 RPC API를 구현할 수 있습니다. API의 네트워크 통신 요소가 RESTful 또는 RPC 인터페이스 표준을 준수하기만 하면 모든 프로그래밍 언어로 나머지 코드를 작성할 수 있습니다.
아키텍처 원칙: RPC와 REST
원격 프로시저 호출(RPC)에서 클라이언트는 서버에서 원격 함수(메서드 또는 프로시저라고도 함)를 직접적으로 호출합니다. 일반적으로 직접 호출 중에 하나 이상의 데이터 값이 서버에 전달됩니다.
반면 REST 클라이언트는 서버에 특정 서버 리소스에 대한 작업을 수행할 것을 요청합니다. 작업은 생성, 읽기, 업데이트 및 삭제(CRUD)로만 제한되며 HTTP 동사 또는 HTTP 메서드로 전달됩니다.
RPC는 기능이나 작업에 초점을 맞추고 REST는 리소스 또는 객체에 초점을 맞춥니다.
RPC 원칙
다음으로 RPC 시스템이 일반적으로 따르는 몇 가지 원칙에 대해 살펴보겠습니다. 그러나 이러한 원칙이 REST처럼 표준화된 것은 아닙니다.
원격 간접 호출
클라이언트는 원격 서버의 함수에 대해 RPC를 직접적으로 호출하는 데, 마치 클라이언트에 로컬로 호출된 것처럼 호출합니다.
파라미터 전달
클라이언트는 일반적으로 로컬 함수와 같은 방식으로 서버 함수에 파라미터를 전송합니다.
스텁
함수 스텁은 클라이언트와 서버 모두에 존재합니다. 클라이언트 측에서는 함수를 직접적으로 호출합니다. 서버에서는 실제 함수를 간접적으로 호출합니다.
REST 원칙
REST 원칙은 표준화되어 있습니다. REST API는 이러한 원칙을 따라야 RESTful로 분류됩니다.
클라이언트-서버
REST의 클라이언트-서버 아키텍처는 클라이언트와 서버를 분리합니다. 각각을 독립적인 시스템으로 취급합니다.
무상태
서버는 클라이언트 요청 사이에 클라이언트의 상태를 기록하지 않습니다.
캐싱 가능
클라이언트 또는 중개 시스템에서는 클라이언트에서 응답의 캐시 가능성을 지정하는지 여부에 따라 서버 응답을 캐시할 수 있습니다.
계층형 시스템
클라이언트와 서버 사이에 중개자가 존재할 수 있습니다. 클라이언트와 서버 모두 이를 알지 못하며 마치 직접 연결된 것처럼 작동합니다.
균일한 인터페이스
클라이언트와 서버는 표준화된 명령 및 메시징 형식 세트를 통해 REST API와 통신합니다. 리소스는 해당하는 URL로 식별되며 이 URL을 REST API 엔드포인트라고 합니다.
작동 방식: RPC와 REST
원격 프로시저 호출(RPC)에서 클라이언트는 HTTP POST를 사용하여 특정 함수를 이름으로 직접 호출합니다. RPC가 작동하려면 클라이언트 측 개발자가 미리 함수 이름과 파라미터를 알고 있어야 합니다.
REST에서 클라이언트와 서버는 GET, POST, PATCH, PUT, DELETE, OPTIONS와 같은 HTTP 동사를 사용하여 옵션을 수행합니다. 서버 리소스 URL을 알기만 하면 개별 함수 이름에 신경 쓸 필요가 없습니다.
다음 표에는 클라이언트가 RPC와 REST에서 유사한 작업을 수행하는 데 사용하는 코드 유형이 나와 있습니다.
| 작업 |
RPC |
REST |
의견 |
| 제품 목록에 새 제품 추가 |
POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
RPC는 함수에 POST를 사용하고 REST는 URL에 POST를 사용합니다. |
| 제품 세부 정보 검색 |
POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 HOST: api.example.com |
RPC는 함수에 POST를 사용하고 JSON 객체로 파라미터를 전달합니다. REST는 URL에 GET을 사용하고 URL로 파라미터를 전달합니다. |
| 제품 가격 업데이트 |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"} |
RPC는 함수에 POST를 사용하고 JSON 객체로 파라미터를 전달합니다. REST는 URL에 PUT을 사용하고 URL 및 JSON 객체로 파라미터를 전달합니다. |
| 제품 삭제 |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 HOST: api.example.com |
RPC는 함수에 POST를 사용하고 JSON 객체로 파라미터를 전달합니다. REST는 URL에 DELETE를 사용하고 URL로 파라미터를 전달합니다. |
주요 차이점: RPC와 REST
다음으로 몇 가지 차이점을 더 살펴보겠습니다.
개발 시기
RPC는 1970년대 후반부터 1980년대 초에 개발되었으며, REST는 2000년에 컴퓨터 사이언티스트 Roy Fielding이 처음 만든 용어입니다.
작업 형식
REST API에는 HTTP 메서드 때문에 표준화된 서버 작업 세트가 있지만 RPC API는 그렇지 않습니다. 일부 RPC 구현은 표준화된 운영을 위한 프레임워크를 제공합니다.
데이터 전달 형식
REST는 동일한 API 내에서 모든 데이터 형식과 JSON 및 XML 같은 여러 형식을 전달할 수 있습니다.
하지만 RPC API의 경우 서버가 데이터 형식을 선택하고 구현 중에 수정합니다. 특정 JSON RPC 또는 XML RPC를 구현할 수 있지만 클라이언트 유연성은 없습니다.
시/도
API와 관련하여 무상태는 클라이언트의 이전 상호 작용에 대한 정보가 서버에 저장되지 않는 설계 원칙을 말합니다. 각 API 요청은 독립적으로 처리되며 서버는 저장된 클라이언트 상태에 의존하지 않고 요청을 처리합니다.
REST 시스템은 항상 무상태 시스템이어야 하지만, RPC 시스템은 설계에 따라 상태 유지 또는 무상태 시스템일 수 있습니다.
사용 시기: RPC와 REST
원격 프로시저 호출(RPC)은 일반적으로 서버에서 작업 결과가 필요한 원격 함수를 호출하는 데 사용됩니다. 복잡한 계산이 필요하거나 프로세스를 클라이언트에 숨긴 상태로 서버에서 원격 프로시저를 트리거하려는 경우에 사용할 수 있습니다.
RPC가 적합한 작업은 다음과 같습니다.
- 원격 디바이스의 카메라로 사진 찍기
- 서버의 기계 학습 알고리즘을 사용하여 사기 행위를 식별
- 원격 뱅킹 시스템에서 한 계좌에서 다른 계좌로 자금 이체
- 원격으로 서버 재시작
REST API는 일반적으로 서버의 데이터 객체에 대한 생성, 읽기, 업데이트 및 삭제(CRUD) 작업을 수행하는 데 사용됩니다. 따라서 REST API는 서버 데이터와 데이터 구조를 균일하게 노출해야 하는 경우에 적합합니다.
REST API가 적합한 작업은 다음과 같습니다.
- 데이터베이스에 제품 추가
- 음악 재생 목록의 콘텐츠 검색
- 사용자 주소 업데이트
- 블로그 게시물 삭제
REST가 RPC를 대체한 이유는 무엇인가요?
지금은 REST 웹 API가 일반적이지만 원격 프로시저 호출(RPC)이 사라진 것은 아닙니다. REST API가 애플리케이션에 일반적으로 사용되는 이유는 개발자가 이해하고 구현하기가 더 쉽기 때문입니다. 하지만 RPC는 여전히 존재하며 사용 사례에 더 적합하다면 RPC가 사용됩니다.
이제는 gRPC와 같은 RPC의 현대적 구현이 더 많이 사용되고 있습니다. 일부 사용 사례에서는 gRPC가 RPC 및 REST보다 성능이 더 좋습니다. gRPC를 사용하면 요청 및 응답 데이터 교환 패턴 대신 클라이언트-서버 통신을 스트리밍할 수 있습니다.
차이점 요약: RPC와 REST
| RPC |
REST |
|
| 무엇인가요? |
원격 클라이언트에서 서버의 프로시저를 마치 로컬인 것처럼 직접적으로 호출할 수 있게 하는 시스템입니다. |
클라이언트와 서버 간의 정형 데이터 교환을 정의하는 일련의 규칙입니다. |
| 용도 |
원격 서버에서 작업을 수행합니다. |
원격 객체에 대한 생성, 읽기, 업데이트 및 삭제(CRUD) 작업을 수행합니다. |
| 가장 적합한 사용 사례 |
복잡한 계산이 필요하거나 서버에서 원격 프로세스를 트리거하는 경우 |
서버 데이터 및 데이터 구조를 균일하게 노출해야 하는 경우 |
| 상태 유지 여부 |
상태 유지 또는 무상태 |
무상태 |
| 데이터 전달 형식 |
서버에서 정의하고 클라이언트에 적용되는 일관된 구조 |
서버에 의해 독립적으로 결정되는 구조. 동일한 API 내에서 여러 형식을 전달할 수 있습니다. |
AWS는 API 요구 사항을 어떻게 지원할 수 있나요?
Amazon Web Services(AWS)는 API를 설계할 때 API 기반의 최신 애플리케이션 및 서비스를 구축, 실행 및 관리하는 데 도움이 되는 다양한 서비스와 도구를 제공합니다. 자세한 내용은 AWS에서 현대적 애플리케이션을 구축하는 방법에 대한 글을 읽어 보세요.
API 요구 사항을 충족하는 데 도움이 될 수 있는 AWS 서비스의 예는 다음과 같습니다.
- Amazon API Gateway는 API를 대규모로 생성, 게시 및 관리하는 데 사용됩니다. API Gateway를 사용하면 컨테이너식 마이크로서비스 아키텍처 및 웹 애플리케이션에 최적화된 REST API를 구축할 수 있습니다.
- Elastic Load Balancing(ELB)은 네트워크 트래픽을 분산하여 애플리케이션 확장성을 개선합니다. 마이크로서비스 간 또는 gRPC 지원 클라이언트와 서비스 간에 gRPC 트래픽을 라우팅하고 로드 밸런싱할 수 있습니다. 따라서 고객 클라이언트 또는 서비스의 기본 인프라를 변경하지 않고도 소프트웨어 아키텍처에서 gRPC 트래픽을 원활하게 관리할 수 있습니다.
- Amazon Virtual Private Cloud(VPC) Lattice는 서비스 간의 통신을 지속적으로 연결, 모니터링 및 보호하는 애플리케이션 네트워킹 서비스입니다. 컴퓨팅 및 네트워크 리소스 규모를 자동으로 조정하여 고대역폭 HTTP, HTTPS 및 gRPC 워크로드를 지원합니다.
지금 계정을 만들어 AWS에서 REST API 및 원격 프로시저 직접 호출(RPC) API를 사용해 보세요.
