"обнови свой код" - хороший пример. Возможно, «init» не нужен, поскольку робот может автоматически инициализироваться при запуске перед поиском заказов. Аналогично, вместо создания «стоп-ордера», вы можете отменить или удалить любые существующие ордера, и робот остановится, когда у него не будет активных ордеров.
Детали API будут сильно зависеть от вашего варианта использования. , В идеале заказ должен быть автономным, чтобы получающий его робот мог выполнить заказ, даже если он частично потерял сетевое соединение. Например, я попытался адаптировать пример из учебника , чтобы отразить ваши предложения:
apiVersion: example.com/v1
kind: Order
metadata:
name: my-move-order
spec:
moveItem:
from: manufacturing
to: logistics
destinationAfterMove: waitingArea
или
apiVersion: example.com/v1
kind: Order
metadata:
name: my-update-order
spec:
installUpdate:
url: https://myproject.com/updates/2020-03-10.tar.gz
Для примера из реального мира. Вы можете посмотреть на проект ewm-cloud-robotics:
Я чувствую, что должен дать предупреждение: декларативный API может быть излишним, если у вас хорошая сеть возможность подключения, в этом случае вы можете предпочесть использовать actionlib с VPN и ROS2. Кроме того, если вы считаете, что ваш API будет слишком сложным для мета-контроллера, и вы хотите использовать язык программирования, отличный от Python или Go, тогда вам следует рассмотреть возможность хранения ваших заказов в базе данных, такой как Redis или MySQL, вместо используя аписервер Kubernetes (последний раз, когда я проверял, не было хорошей клиентской поддержки для языков, отличных от Python или Go).