REST vs RPC

REST와 RPC의 차이를 알아보자

1. REST

REST?

  • REpresentational State Transfer
  • 상태값을 주고 받을 때, 구조 스타일

RESTful API

  • HTTP 프로토콜 기반(HTTP 1.1)
  • 리소스(자원)는 URI로 표현하며, 고유해야한다.
  • URI는 단순하고 직관적인 구조이어야 한다.
  • 처리 결과를 status code로 사용한다.
  • 리소스 상태는 HTTP Methods를 활용해 구분한다.

    • CRUD Operation
      1. POST: Create(추가/생성)
      2. GET: Read(조회)
      3. PUT: Update(수정)
      4. DELETE: Delete(삭제)
  • xml 또는 json을 활용해서 데이터를 전송한다.
  • 동사보다는 복수 명사를 기준으로 사용한다.
    • 하위 자원을 표현하기 위해 /를 사용한다.
GET /users          : 모든 사용자의 정보를 가져온다.
GET /users/{id}     : id에 해당하는 사용자의 정보를 가져온다.
POST /users         : 새로운 사용자를 추가한다.
PUT /users/{id}     : id에 해당하는 사용자 정보를 수정한다.
DELETE /users/{id}  : id에 해당하는사용자 정보를 삭제한다.

특징

무상태성(stateless)

  • 클라이언트의 컨텍스트를 서버쪽에 유지하지 않는다.
  • 각 API 서버는 들어오는 요청만 메세지로 처리한다.

캐쉬 가능(cacheable)

  • HTTP 프로토콜 표준에서 사용하는 ‘Last-modified’ 태그나 E-tag를사용하면 구현할 수 있다.
    • client가 HTTP GET을 ‘Last-Modified’ 값과 함께 보냈을 때, 컨텐츠 변화가 없으면 ‘304 Not Modified’를 리턴하고 client는 자체 캐쉬에 저장된 값을 사용한다.
  • 네트워크 응답시간과 성능, 서버의 자원 사용률을 향상시킬 수 있다.

Client-Server 구조

  • 서버는 API를 제공하고 제공된 API를 이용해 비즈니스 로직 처리 및 저장을 책임진다.
  • 클라이언트는 사용자 인증이나 컨텍스트(세션/로그인) 등을 직접 관리하고 책임진다.

장점

  • 낮은 복잡도
  • 완만한 학습 곡선
  • 높은 개발 생산성

2. RPC

RPC?

  • Remote Procedure Call
  • 원격에 위치한 프로그램을 로컬에 있는 프로그램처럼 사용할 수 있다.
  • 개발자는 network 통신과 관련된 작업은 신경쓰지 않아도 된다.
  • 실행 인자와 실행할코드를 명확하게 해야 한다.
  • IDL(Interface Definition Language)를 사용해 서버의 호출 규약을 정의한다.

개념

Stub

  • 클라이언트 보조 객체
  • 그 자체로는 제 기능을 발휘하지 못한다.
  • 원래 개체가 무엇인지 알아낼 수 있는 참조 역할
  • 원 개체의 기능조작을 위임받은 위임자 역할
  • 객체와 동일한 비즈니스 메소드를 가진 인터페이스를 구현

흐름

  1. 클라이언트가 스텁의 비즈니스 메소드를 호출하면, 호출된 메소드명과 매개변수로 전달된 값들이 스트림 형태로 서버에 전달된다.
  2. 메소드 호출 결과를 기다린다.
  3. 반환받은 결과값을 로컬 컴퓨터에서 처리한 것처럼 클라이언트에 결과값을 전달한다.

Skeleton

  • 서버 보조 객체
  • 요청 메세지를 수신해 이해하고 정보를 서비스 측 비즈니스 객체로 전달한다.

흐름

  1. 스트림을 분석해 어떤 메소드가 요청되었는지를 파악한다.
  2. 서버에 있는 객체의 비즈니스 메소드를 호출한다.
  3. 실행 결과값은 다시 클라이언트로 전달한다.


RPC 개념

장점

  • 고유 프로그램 개발에 집중 가능
  • 프로세스간 통신 기능을 비교적 쉽게 구현 가능
  • 다양한 언어를 가진 환경에서 쉽게 확장 가능

단점

  • 호출 실행과 반환 시간이 보장되지 않는다.

Reference