Czy zaprojektowałbyś kontrolne API łazika Marsa następnej generacji, aby był REST-owy zamiast RPC?

Question

Przebacz mi, jeśli to jest bycie "dyskusyjnym" pytaniem, ale naprawdę chciałbym, aby docenił odpowiedź tak/nie, z odpowiednim wyjaśnieniem.

Załóżmy, że musisz zaprojektować i zaimplementować interfejs sterowania API dla robota, powiedzmy kolejnego generatora Mars Rover z . Czy tworzysz ten interfejs API zgodnie z zasadami RESTful , czy używasz klasycznego RPC, takiego jak XMLRPC?

Pytam o to, ponieważ muszę zrobić coś podobnego, choć "robot" to zbiór maszyn wirtualnych. Zostałem poproszony przez jednego raczej przekonującego inżyniera, znanego rzecznika REST, aby API RESTful. Nigdy nie stosowałem zasad REST i staram się zobaczyć, jak pasują do projektowania niskopoziomowych API między procesami. REST wydaje się natchniony tematem interakcji z repozytorium danych, które można modyfikować, zwykle z wielu przeskoków. To, co próbuję zrobić, bardziej przypomina kontrolowanie robota. Widzę, jak można argumentować, że robot jest, w abstrakcji, tylko repozytorium danych - "PUT left turn", "PUT travel 100 metrów", "GET temperatura zewnętrzna". Ale wydaje się, że jest to raczej wymyślny model. Z pewnością nie otrzymam korzyści z buforowania lub proxy ("Witaj, JPL? To jest współtworzenie Akamai w Canberze Teraz przejmujemy Rovera, ok?")

Tak, jest to architektura RESTful przydatne tutaj? Czy nadal jest lepszy od RPC nawet , gdy interakcja jest tak wąsko skoncentrowana?

Answer 1

Myślę, że REST miałoby większy sens niż tradycyjny RPC. Nawet Micorosft Robotics Studio runtime application model używa REST.

Robot może składać się z różnych zasobów, które są identyfikowane przez URI, w tym jeden dla każdego czujnika i elementu wykonawczego lub jego złożonych abstrakcji.

REST kładzie nacisk na gwarantowanie efektów ubocznych określonych metod, a także ułatwia buforowanie, co może być przydatne w przypadku kontrolowania i monitorowania odległego robota. I tylko dlatego, że możesz użyć REST, to nie musi być musi być protokołem HTTP.

Metoda BEZPIECZNA i IDEMPOTENTOWA, taka jak GET, jest przydatna w śledzeniu stanu robota i odpytywaniu jego danych z czujników. Możesz użyć czegoś takiego jak nagłówek Last-Modified, aby pobrać buforowane dane z czujników, które nie zmieniają się często (np. Poziomy wilgotności lub światła).

Do dużych odległości można używać przekaźników proxy do buforowania.

W przypadku poleceń, które przesuwają robota, należy użyć polecenia POST, w którym każda taka wiadomość spowoduje zmianę robota (np. Skręć w prawo). Kod statusu może zostać zwrócony, wskazując, czy polecenie zostało natychmiast wykonane, czy też w kolejce do przetworzenia.

Stan bezwzględny dowolnych zasobów można ustawić za pomocą czegoś takiego, jak PUT, gdzie wiele wiadomości nie zmieni niczego więcej niż tylko jedną wiadomość (np. Wskaż północ biegun lub przyciemnione oświetlenie przednie do 10% jasności). Pozwala to na niezawodne przesyłanie wiadomości w przypadku prawdopodobieństwa zagubienia wiadomości na trasie.

Nowy zasób można również utworzyć za pomocą operacji podobnej do POST, na przykład procedury zbierania danych i zestawu parametrów. Żądanie POST może odesłać wynik CREATED z identyfikatorem URI dla nowego zasobu, który może być użyty do usunięcia, gdy nie jest już potrzebny.

Grupa robotów może również komunikować się ze sobą za pomocą tego samego protokołu opartego na REST i może cieszyć się tymi samymi korzyściami.

To prawda, że ​​w przypadku czegoś prostego, jak jedna osoba kontrolująca jednego izolowanego robota lokalnego, interfejs API REST może być przesadzony. Jednak w przypadku wieloużytkowników i/lub niewiarygodnych kanałów komunikacyjnych i/lub sieci w skali REST należy wziąć pod uwagę.

Answer 2

Zasady REST zapewniają, że aplikacja skaluje się dobrze i dobrze współpracuje z pośrednikami w Internecie (serwery proxy, buforowanie itp.). Jeśli twoja sieć "wirtualnej maszyny" ma dużą skalę, korzystna może być architektura REST. Jeśli budujesz sieć na małą skalę, REST nie byłby tak przekonujący.