[Network] RPC vs REST 비교하기

RPC (Remote Procedure Call) vs REST (Representational State Transfer)

	RPC	REST
배경	분산 네트워크 환경에서 더 편하게 프로그래밍 하기 위해 등장	프론트엔드와 백엔드가 분리되기 시작 멀티플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색
개념	프로세스간 통신을 위해 사용하는 IPC(Inter Process Communication) 방법의 한 종류이다. 원격지의 프로세스에 접근하여 프로시저 또는 함수를 호출하여 사용한다.	REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일이다. REST는 네트워크상에서 Client와 Server 사이의 통신 방식 중 하나이다.
개념확장	다양한 언어와 프레임워크로 개발되는 경우가 잦은데, 이런 구조에서는 프로토콜을 맞춰서 통신해야 하는 비용이 발생한다. RPC를 이용하여 언어에 구애받지 않고, 원격에 있는 프로시저를 호출하여 비즈니스 로직에 집장하는 개발을 할 수 있다.	HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 자원에 대한 CRUD Operation을 적용한다.
목표	- 클라이언트-서버간의 커뮤니케이션에 필요한 상세한 정보는 감추고 클라이언트는 일반 메서드를 호출하는 것처럼 호출하면 된다. - 서버도 마찬가지로 일반 메서드를 다루는 것처럼 원격 메서드를 다룰 수 있다.	구성 요소 상호작용의 규모 확장성 인터페이스의 범용성 구성 요소의 독립적인 배포로 버전 관리가 가능하다.
장점	고유 프로세스 개발 집중이 가능하다. 하부 네트워크 프로토콜에 신경쓰지 않아도 되기 때문이다. 프로세스간 통신 기능을 비교적 쉽게 구현하고 정교한 제어가 가능하다.	쉬운 사용 - 메세지가 의도하는 바를 명확하게 파악할 수 있다. 필요한 데이터를 body에 표현할 수 있게 구성되어, json, XML등 다양한 언어를 이용하여 작성할 수 있다. 기존 웹 인프라를 그대로 이용할 수 있다.
단점	호출 실행과 반환 시간이 보장되지 않는다. 네트워크 구간을 통하여 RPC 통신을 하는 경우, 네트워크가 끊겼을 때 치명적 문제 발생함 보안이 보장되지 않는다.	사용할 수 있는 메서드가 제한적이다. 표준이 없어 관리가 어렵다. (공식화된 API 디자인 가이드가 존재하지 않음)
구현체	- Google의 ProtocolBuffer - Facebook의 Thrift - Twitter의 Finalge

• Caller / Callee
  • 사용자(Client / Server)가 필요한 비즈니스 로직을 작성하는 Layer
  • IDL(interface definition language)로 작성
• Stub
  • Stub Compiler가 IDL 파일을 읽어 원하는 Language로 생성.
  • Parameter Object를 Message로 marshalling/unmarshalling하는 Layer
• RPC RunTime
  • Server와 Client를 Binding하는 Layer
  • 커뮤니케이션 중 발생한 에러 처리도 진행