¿Diseñarías la API de control del rover de Mars de próxima generación para que sea RESTful en lugar de RPC?

Question

Perdóneme si esto llega a ser una pregunta de "discusión", pero realmente agradecería una respuesta sí/no, , con una explicación adecuada.

Supongamos que tiene que diseñar e implementar una API de control para un robot, por ejemplo, la siguiente generación Mars Rover. ¿Diseña esta API de acuerdo con los principios RESTful , o utiliza una RPC clásica, como XMLRPC?

Lo pregunto porque tengo que hacer algo similar, aunque el "robot" es una colección de máquinas virtuales. Me urge un ingeniero bastante persuasivo, un conocido defensor de REST, para que la API RESTABLEZCA. Nunca utilicé los principios de REST, y estoy luchando para ver cómo encajan en el diseño de API de bajo nivel entre procesos. REST parece estar infundido con el tema de interactuar con un repositorio de datos modificable, generalmente a muchos pasos de distancia. Lo que estoy tratando de hacer se parece más a controlar de cerca un robot. Puedo ver cómo se podría argumentar que el robot es, en abstracto, solo un depósito de datos: "PUT a la izquierda", "PUT viaja 100 metros", "GET fuera de la temperatura". Pero este parece ser un modelo bastante artificial. Ciertamente no recibiré ningún beneficio del almacenamiento en caché o un proxy ("Hola, JPL? Este es el co-lo de Akamai en Canberra. Ahora estamos tomando el Rover, ¿de acuerdo?")

Entonces, es una arquitectura RESTful útil aquí? ¿Sigue siendo superior a RPC incluso cuando la interacción se enfoca tan estrechamente?

Answer 1

Creo que REST tendría más sentido que el RPC tradicional. Incluso el Micorosft Robotics Studio runtime application model usa REST.

El robot puede constar de diferentes recursos que se identifican por URI, incluido uno para cada sensor y actuador o abstracciones compuestas de los mismos.

REST pone énfasis en garantizar los efectos secundarios de ciertos métodos y también facilita el almacenamiento en caché, que pueden ser útiles para controlar y controlar un robot distante. Y solo porque puede usar REST no es tiene que ser el protocolo HTTP.

Un método SEGURO e IDEMPOTENTE como GET, sin embargo, es bueno para rastrear el estado del robot y consultar sus datos de sensor. Puede utilizar algo como el encabezado Last-Modified para recuperar los datos del sensor en caché que no cambian con frecuencia (por ejemplo, humedad o niveles de luz).

Para largas distancias puede usar proxies de retransmisión para el almacenamiento en caché.

Para los comandos que mueven el robot, se utilizará algo así como POST donde cada uno de esos mensajes cambiará el robot (por ejemplo, gire a la derecha). Se puede devolver un código de estado que indica si el comando se ejecutó inmediatamente o se puso en cola para su procesamiento.

El estado absoluto de cualquier recurso se puede establecer utilizando algo como PUT, donde los mensajes múltiples no cambiarán las cosas más que un solo mensaje (por ejemplo, señalar hacia el polo norte o atenuar las luces delanteras al 10% de brillo). Esto permite mensajes confiables en caso de que se pierdan los mensajes durante el camino.

También se puede crear un nuevo recurso mediante una operación similar a POST, por ejemplo, una rutina de recopilación de datos y un conjunto de parámetros. La solicitud POST puede enviar un resultado CREADO con un URI para el nuevo recurso, que se puede utilizar para ELIMINAR cuando ya no sea necesario.

Un grupo de robots también pueden hablar entre ellos utilizando el mismo protocolo basado en REST y pueden disfrutar de los mismos beneficios.

De acuerdo, para algo tan simple como una persona que controla un único robot local aislado, una API REST puede ser excesiva. Pero para multiusuario y/o canales de comunicaciones no confiables y/o redes de escala web, REST es algo a considerar.

Answer 2

Los principios de REST aseguran que su aplicación se adapte bien y que funcione bien con los intermediarios de Internet (proxies, caching, etc.). Si su red de "máquina virtual" es de gran escala, una arquitectura REST podría ser ventajosa. Si está construyendo una red a pequeña escala, entonces REST no sería tan convincente.