With new http/ws endpoints discovery process is no longer very coherent

[tkurki]

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.

[tkurki]

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)

[rob42]

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.