REST보다 RPC-ish 접근 방식이 언제 더 적합합니까?

Steve Vinoski의 REST, Reuse 및 Serendipity 에 대한 이 강연 을 본 후 , (XML-) RPC-ish 설정을위한 그린 필드 프로젝트에 REST가 더 나은 방법으로 해결할 수없는 비즈니스 사례가 있는지 궁금합니다 .

그가 언급 한 몇 가지 RPC 문제 :

• 언어에 중점을 두십시오 (분산 시스템을 다른 방식이 아닌 언어에 맞추십시오).
• "로컬로 표시"(규칙이 아닌 예외로 실패 및 대기 시간에 대처)
• 언어와 무관하지만 언어를 통틀어 주요 기능으로 "함수 호출"기능이 있습니다.
• IDL 상용구
• 타입 안전의 환영
• 그리고 몇 가지 더 ...

약간만 표현하면 RPC와 REST의 일부 Google 순간 검색 결과는 다음과 같습니다.

일반적으로 RPC는 REST보다 훨씬 더 많은 언어 통합을 제공합니다. 언급했듯이, 특히 단일 분산 시스템에 여러 언어로 작성된 코드를 실행하는 여러 호스트가 포함 된 경우 규모, 오류 처리, 유형 안전 등과 관련하여 여러 가지 문제가 발생합니다. 그러나 RPC, REST 및 둘 다를 동시에 사용하는 비즈니스 시스템을 작성한 후에 특정 경우 RPC over REST를 선택해야하는 몇 가지 이유가 있음을 알게되었습니다.

RPC가 더 적합하다는 것을 알게 된 경우는 다음과 같습니다.

• 단단한 커플 링. 시스템의 (분산 된) 구성 요소는 함께 작동하도록 설계되었으며 하나를 변경하면 다른 모든 요소에 영향을 줄 수 있습니다. 향후 다른 시스템과 통신하도록 구성 요소를 조정해야 할 가능성은 거의 없습니다.
• 안정적인 커뮤니케이션. 구성 요소는 대기 시간 문제, 패킷 손실 등이 발생할 가능성이 거의없는 동일한 호스트 또는 네트워크에서 완전히 서로 통신합니다. 그러나 여전히 이러한 경우를 처리하도록 시스템을 설계해야합니다.
• 통일 언어. 모든 (또는 대부분의) 구성 요소는 단일 언어로 작성됩니다. 다른 언어로 작성된 추가 구성 요소가 나중에 추가 될 가능성은 없습니다.

IDL에 대한 요점과 관련하여 REST 시스템에서 REST 요청 및 응답의 데이터를 사용중인 내부 데이터 표시로 변환하는 코드도 작성해야합니다. IDL 소스 (좋은 설명 포함)는 인터페이스의 문서 역할을 할 수 있으며 REST API에 대해 별도로 작성하고 유지 보수해야합니다.

위의 세 가지 항목은 더 큰 시스템의 하나의 구성 요소를 빌드하려고 할 때 종종 발생합니다. 필자의 경험에 따르면 이러한 구성 요소는 종종 해당 하위 시스템이 독립적으로 장애를 일으켜 다른 하위 시스템이나 전체 구성 요소의 전체 장애를 유발하지 않아야하는 구성 요소입니다. 이러한 목표를 달성하기 위해 많은 시스템이 Erlang으로 작성되었으며 경우에 따라 다른 언어로 시스템을 작성하고 RPC를 사용하여 이러한 이점을 얻는 것보다 Erlang이 더 나은 선택 일 수 있습니다.

대부분의 엔지니어링 문제와 마찬가지로 프로세스 간 통신 문제에 대한 단일 솔루션은 없습니다. 설계중인 시스템을보고 사용 사례에 가장 적합한 선택을해야합니다.

제품이 데이터 센터 전체에서 확장되고 고 가용성 및로드 밸런싱을 수행 할 때 REST의 주요 이점이 있습니다.

그러나 소규모 프로젝트에 대해 생각하십시오. 한 시간에 몇 백 건의 요청이있는 웹 서비스가 필요하십니까? WCF는 모든 전송 문제를 처리합니다. 네트워크를 통해 객체를 전송하기위한 편리한 인터페이스가 있으며 application.config 파일 만 사용하여 프로그래밍없이 네트워크 연결을 구성, 암호화 및 인증 할 수 있습니다.

실제로 둘 다 가질 수 있습니다. RestRPC for Grails와 같은 플러그인은 메소드 호출을 가로 채고 원하는대로 처리 할 수있는 주석을 제공합니다.