specification
specification copied to clipboard
With new http/ws endpoints discovery process is no longer very coherent
Now that we have explicit endpoints like ../snapshot
, ../playback
, ../actions
and ../access/requests
the discovery process is no longer very coherent, as the /signalk response points to .../api
and ../stream
and the new endpoints are at the same level.
Do we just state that the other endpoints are siblings of these or add something to the /signalk response? Not being backwards compatible is not really an option at this stage.
From @mxtommy:
Trying to figure out best way to automate sensor auth with the new device request stuff :slightly_smiling_face: Currently (without Auth), I'm doing a mDNS request for the signalk-ws/tcp service.
If that works great nothing more to do. If not I can manually set IP and port for Websocket, and that's it it connects :slightly_smiling_face:
So if I want to do this auth stuff as automated as possible, I need to discover the URL to post the access request. From the server installs I've seen so far, it seems ws/http host/port is always the same. Is it a safe assumption to use that? If not, how do I discover the URL for access requests? :slightly_smiling_face: (I could poke the main /signalk endpoints url, but the URL it returns is not the same as the access request one (/signalk/v1/api vs signalk/v1/requests)
The endpoints are not services, they are transports, http,ws,tcp etc. The ../snapshot
etc are services, and are the same on every transport. To get a snapshot over tcp send a GET message with the time
attribute set. (Which brings up another task, the message formats need updating to reflect the REST /snapshot, /playback, and /history parameters. I will do a separate PR.)
So mxtommy can grab mDNS, connect over his preferred transport (tcp?) and issue a signalk AUTH message. The urls are only relevant to the http transport.