RPC vs REST

- RPC는 원격 서버의 함수를 호출해서 결과를 얻음

- REST는 API를 통해 원격 서버에 있는 리소스에 대한 상태를 주고 받음

 

REST; GET/posts/{id} 와 같이 원격 서버의 리소스에 접근할 수 있는 직접적인 통로 제공

RPC; URL 엔드포인트는 그냥 통로일 뿐 원격 서버와 클라인트가 공통으로 사용하는 라이브러리를 사용해 $client->find($id)와 같이 통신

 

HTTP 기반의 REST가 유행하면서 RPC는 많이 사라짐

REST의 경우 호출하는 parameter와 응답 값이 명시적이지 않기 때문에 오류의 여지가 많고 JSON을 HTTP를 통해 쏘기 때문에, 속도가 떨어짐

 

페이스북은 Thrift라는 바이너리 RPC 프레임워크를 발표

 

---

Socket

- API로 제공으로 쉽게 구현 가능

 

하지만 보장해야함

1. 네트워크는 언제나 빠르고 장애가 없음

2. 서버는 클라이언트가 요청시 언제든 즉시 응답 가능

3. 클라이언트는 언제든 서버와 바로 연결 가능

 

참고

https://webnautes.tistory.com/1381

파이썬 소켓 프로그래밍 - 클라이언트 / 서버 예제

 

---

RPC : Remote Procedure Call

- 원격에 있는 함수를 호출해주는 기능

 

requet parameter와 response parameter를 알아야하기 때문에 양쪽 인터페이스를 정의 후 코드 생성

-> skeleton과 stub코드라고 불림

 

 

서버-클라이언트 간의 약속 만들기

- RPC 프레임워크는 Interface Definition Language를 제공함

- RPC 프레임워크 종류

• Protocol Buffers (by Google)
• Apache Thrift (by Facebook)
• Apache AVRO
• GRPC (bu Google) 

 

이러한 기술은 socket을 활용해서 하던 복잡한 네트워크와 하부 영역에 대한 캡슐화를 통해 

서버-클라이언트 간 통신을 간단한 메소드 함수 호출로 바꾼 시도

 

그러나,

복잡성, 어려움, 보안 등으로 사용이 적어짐...

 

보다 익숙한 WEB을 활용

 

---

REST (REpresentational State Transfer)

- HTTP 1.1을 사용

   - get/post/put/delete method 사용 가능

- URI를 자원으로 표현

- 처리결과를 Status Code로 사용

 

 

HTTP request/response 메세지 구조

 

참조 : https://rtfmplz.github.io/2017/05/08/rpc2rest