New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional HowTos #2
Comments
Hi there, What REST API do you mean? The management API of the Trusted Connector? The existing examples glue also to HTTP. |
Lets say I have an existing REST service, for example: https://airquality-frost.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1 This example is publicly available, but our real service would, of course, not be. A graphical GUI for this demo service can be found at: https://api4inspire.k8s.ilt-dmz.iosb.fraunhofer.de/servlet/is/127/ In the MQTT example I found (https://industrial-data-space.github.io/trusted-connector-documentation/docs/rest/) the client doesn't actually seem to use MQTT. The client seems to be a REST API that gets data pushed into it using HTTP, not MQTT. In other words, the client is actually a http server. |
Hi there, the example works like this: The client (provider) publishes to a mqtt server. The route picks that up and transmits it to the server (consumer). There it is transferred to a REST endpoint. You can instead publish to MQTT on the server side as well. Drop me a mail if things are unclear, please. |
So how does the MQTT server on the provider side know which topics have subscribers? Or do all topics need to be pre-determined? |
They need to be predetermined. You could thin about embedding this in the info model, but after all this is the application layer. For "forwarding" REST APIs, you can create a REST interface inside of a Camel route. You will also get the response routed back to you. This is basic Camel then, the IDSCP is just wrapping the payload. |
Two HowTos that would be very useful additions to the documentation would be for the use cases:
The text was updated successfully, but these errors were encountered: