Re: Transform Services https URL to websocket URL and related questions
Hello Wim,
the idea behind multiple service URLs at one single App Service is following:
It is possible to create different App Objects with different "Grant access to APIs" configurations. For example we have an App Service with two App Objects (+ corresponding service URLs on App Service side):
- /someservice
- has WebSocket and PbxApi enabled
- any User with access to this App can also use the PbxApi (by connecting to /PBX0/APPS/websocket URL at tthe PBX and doing AppLogin to app=someservice). This is usually not what you want to give to any user.
- /someservice-api
- has no settings at "Grant access to APIs"
- any User with access to this App can do AppLogin to the App Service and use some specific API implemented by the App Service
- this User could also connect to the PBX WebSocket (/PBX0/APPS/websocket), but would get no access to any APIs at the PBX
Now, if we take a look on the Devices App, the only difference is, that User with the access to innovaphone-devices-api has no UI of the Devices App itself, but the same API access level.
This means for your specific case, it would be OK to use innovaphone-devices-api, since it seems to be a server application and no UI is required.
> IService* devicesService =
> _servicesApi->GetService("com.innovaphone.devices");
> ...
> devicesService->GetWebsocketUrl()
>
> I see from the logging the websocket URL is
> wss://10.0.0.241/xqting.be/devices/
> What is the logic to move from the https:// to the wss:// URL.
> Because there is a part "stripped" of the https URL. Is it always
> the last part that must be removed, or, is this wss url constructed
> in a different way?
Yes, the implementation of GetWebsocketURL just replaces http by ws and removes last path part (which is usually some specific app, like devices-api). As result you have a webserver path of a service, which can be used to establish a websocket connection to this service.
Out apps will accept a websocket connection via URL without this last app name defined (so wss://10.0.0.241/xqting.be/devices/ will work with Devices ). However, any other App Service could implement limitations or other behaviour, depending on the URL used to connect.
>and finally: what happens if there are for example multiple
> instances of the files apps? Are there then also mutliple instance
> of the files api? and if so, how this URL composition work then?
Recommended webserver path for an instance is "/<domain>/<instancename>" and is extended by <app-name> (which is usually at least app name, or additional app/service api url )
The multiple instances will have different webserver paths with same APIs/URLs each:
- /first.example.com/someservice/company-someservice
- /first.example.com/someservice/company-someservice-api
- /second.example.com/someservice/company-someservice
- /second.example.com/someservice/company-someservice-api
Best Regards
Andreas Fink