The problem is not that there is no standard -- there is, it's called ROS. The problem is that manufacturers are not interested in opening their robots up to that degree.
Also, REST is a terrible idea for interacting with robots. REST is call-response based. But with Robots a pub/sub (like ROS or MQTT) or a blackboard data architecture (like what we used in Transitive Robotics) is much more efficient and natural.
On ROS being the standard — you're right that ROS exists,
but adoption outside research/academia is still fragmented.
Boston Dynamics, Universal Robots, and most industrial arms
don't natively speak ROS — teams still write glue code.
RoboAPI is trying to be that glue as a managed layer rather
than a DIY problem.
On REST being wrong for robots — completely agree on the
pub/sub point. REST is the entry point for developer
familiarity but RoboAPI already has WebSocket streaming for
telemetry. The next step is moving commands to pub/sub too.
Interesting that you mention Transitive Robotics — the
blackboard pattern is something I've been thinking about
for the fleet layer.
What would the ideal architecture look like from your
experience? MQTT for commands, WebSocket for telemetry,
REST only for configuration?
The problem is not that there is no standard -- there is, it's called ROS. The problem is that manufacturers are not interested in opening their robots up to that degree.
Also, REST is a terrible idea for interacting with robots. REST is call-response based. But with Robots a pub/sub (like ROS or MQTT) or a blackboard data architecture (like what we used in Transitive Robotics) is much more efficient and natural.
Fair points, and appreciate the pushback.
On ROS being the standard — you're right that ROS exists, but adoption outside research/academia is still fragmented. Boston Dynamics, Universal Robots, and most industrial arms don't natively speak ROS — teams still write glue code. RoboAPI is trying to be that glue as a managed layer rather than a DIY problem.
On REST being wrong for robots — completely agree on the pub/sub point. REST is the entry point for developer familiarity but RoboAPI already has WebSocket streaming for telemetry. The next step is moving commands to pub/sub too. Interesting that you mention Transitive Robotics — the blackboard pattern is something I've been thinking about for the fleet layer.
What would the ideal architecture look like from your experience? MQTT for commands, WebSocket for telemetry, REST only for configuration?