REST API?

[matthijsramlab]

Any indications when this will be finished?

[mxgrey]

After some research into integrating a REST API into SOSS, it's not entirely clear to us how much it makes sense to use SOSS to interface with REST APIs. The REST model does not have a clearly generalized way to integrate with the pub/sub models that SOSS been targeting so far. It seems like a lot of semantic understanding of a REST API is required in order to weave it into a pub/sub system.

In our use cases so far, we've found it's more expedient to generate a Python client for the REST API using Swagger. You can find an example of such a generated client here. Then a human who understands how the two ends of the system should tie together can use the generated code to create a simple rclpy node to convert between the RESTful API and the pub/sub API. At that point, SOSS could be used to translate from rclpy node to any of the other pub/sub middlewares that SOSS supports.

In theory there's nothing to prevent SOSS from being used in a similar fashion, except that:

1. SOSS is currently implemented in native C++, and we had trouble finding any appealing libraries for implementing REST clients in C++.
2. We aren't aware of a REST API code generation tool for C++ that is as appealing as Swagger.

If anyone has recommendations for pipelines to generate C++ REST API client code, we'd be happy to revisit this matter.

[matthijsramlab]

@mxgrey many thanks for your elaborate answer.

It seems like a lot of semantic understanding of a REST API is required in order to weave it into a pub/sub system.
I agree and using swagger to generate an API looks promising.

What we want is to 'open' some parts of our system so that these values can be viewed in a web app (probably python web server) and parameters can be altered. Probably using web sockets is even a better option. Do you have suggestions for our use case?

[mxgrey]

Sorry for the delayed response, but I think if you're envisioning a constant data stream over a wired connection, then websockets make a lot of sense. Otherwise if it's an intermittent connection (perhaps with a wifi gap in the middle) then a REST API might be more suitable.

Realistically both are likely to work just fine in either case, so I think the decision will really depend on the broader context of what's most familiar to your developers, what's demanded by your clients, and what software tools are most accessible for you.