차세대 화성 탐사선의 제어 API를 RPC 대신 RESTful으로 설계 하시겠습니까?

Question

이 질문이 "토론"질문이 될 경우 용서해주십시오. 그러나 실제로는 적절한 설명과 함께 예/아니오 대답을 부탁합니다. .

로봇에 대한 제어 API를 설계하고 구현해야한다고 가정하면 다음 세대 화성 탐사차입니다. RESTful 원칙에 따라이 API를 설계하거나 XMLRPC와 같은 고전적인 RPC를 사용합니까?

"로봇"은 가상 머신의 모음이지만 비슷한 것을해야하기 때문에이 질문을드립니다. 나는 REST 옹호자로 잘 알려진 기술자가 API를 RESTful하게 만들 것을 촉구 받는다. 필자는 REST 원칙을 사용한 적이 없으며 저수준의 프로세스 간 API를 설계하는 데 얼마나 적합한지를 고민하고 있습니다. REST는 수정할 수있는 데이터 저장소와 상호 작용한다는 주제로 붐비고있다. 내가하려고하는 것은 로봇을 면밀히 제어하는 ​​것과 같은 느낌입니다. 나는 로봇이 초록에서 단지 "PUT left turn", "PUT travel 100 meters", "Got outside temperature"와 같이 추상적 인 데이터 저장소라고 주장 할 수있다. 그러나 이것은 오히려 고안된 모델 인 것 같습니다. 캐싱이나 프록시 ("안녕하세요, JPL? 이것은 캔버라의 Akamai co-lo입니다. 우리는 지금 로버를 인수하고 있습니다.")

그래서 RESTful 아키텍처입니다. 여기에 유용한가? 상호 작용이 너무 좁게 집중 될 때 심지어 RPC보다 여전히 우수합니까? ?

Answer 1

REST는 기존 RPC보다 더 의미가 있다고 생각합니다. Micorosft Robotics Studio runtime application model조차도 REST를 사용합니다.

로봇은 URI로 식별되는 다양한 리소스로 구성 될 수 있습니다. 여기에는 각 센서 및 액추에이터 또는 복합 추상화에 대한 리소스가 포함됩니다.

REST는 특정 메소드의 부작용이 무엇인지 보장하는 데 중점을 두며, 캐싱을 용이하게합니다. 둘 다 먼 로봇을 제어하고 모니터링하는 것과 같은 것에 유용 할 수 있습니다. 그리고 REST를 사용할 수 있기 때문에 은이 HTTP 프로토콜이어야합니다.

GET과 같은 SAFE 및 IDEMPOTENT 방법은 로봇의 상태를 추적하고 센서 데이터를 폴링하는 데 적합합니다. Last-Modified 헤더와 같은 것을 사용하여 자주 변경되지 않는 캐시 된 센서 데이터 (예 : 습도 또는 광도)를 검색 할 수 있습니다.

장거리의 경우 캐싱에 릴레이 프록시를 사용할 수 있습니다.

로봇을 움직이는 명령의 경우 모든 메시지가 로봇을 바꿀 (예 : 우회전) 때 POST와 같은 것이 사용됩니다. 명령이 즉시 실행되었거나 처리 대기 중임을 나타내는 상태 코드가 리턴 될 수 있습니다.

자원의 절대 상태는 여러 메시지가 단일 메시지 (예 : 북극점을 가리 키거나 전조등을 10 % 밝기로 조정) 이상으로 사물을 변경하지 않는 PUT과 같은 것을 사용하여 설정할 수 있습니다. 이렇게하면 메시지가 길을 잃을 확률이 높은 경우에 신뢰할 수있는 메시징이 가능합니다.

데이터 수집 루틴 및 매개 변수 세트와 같은 POST와 유사한 작업을 통해 새 리소스를 생성 할 수 있습니다. POST 요청은 새 자원에 대한 URI가있는 CREATED 결과를 다시 보낼 수 있으며 더 이상 필요하지 않을 때 삭제에 사용할 수 있습니다.

로봇 그룹도 동일한 REST 기반 프로토콜을 사용하여 서로 이야기 할 수 있으며 동일한 이점을 누릴 수 있습니다.

로컬 로봇 하나를 제어하는 ​​사람처럼 간단하게 REST API가 과도 할 수도 있습니다. 그러나 다중 사용자 및/또는 신뢰할 수없는 통신 채널 및/또는 웹 스케일 네트워킹의 경우 REST가 고려해야 할 사항입니다.

Answer 2

REST 원칙은 응용 프로그램의 확장이 잘되고 인터넷상의 중개자 (프록시, 캐싱 등)와 잘 작동하는지 확인합니다. "가상 시스템"네트워크가 대규모 인 경우 RESTful 아키텍처가 유리할 수 있습니다. 소규모 네트워크를 구축하는 경우 REST가 매력적이지는 않습니다.