Closed tkurki closed 8 years ago
I can take this.
Quick question: the example above and the doc have
"signalk-http": "http://192.168.1.2/signalk/v1"
but the linked guide has that endpoint at
/signalk/v1/api
Should the actual JSON returned be
"signalk-http": "http://192.168.1.2/signalk/v1/api"
V1 is not just v1/api, it is also v1/stream. V2 might have v2/foo in addition.
Right, which is why the additional part would be needed. IOW the full JSON response should be:
{
"endpoints": {
"v1": {
"version": "1.1.2",
"signalk-http": "http://192.168.1.2/signalk/v1/api/",
"signalk-ws": "ws://192.168.1.2:34567/signalk/v1/stream"
},
"v3": {
"version": "3.0",
"signalk-http": "http://192.168.1.2/signalk/v3/api/",
"signalk-ws": "ws://192.168.1.2/signalk/v3/stream"
}
}
}
That makes the value of the "signalk-http"
key the actual URI of the endpoint. Without that, the client application needs to assume that the HTTP endpoint is actually at ./api
and the WS endpoint at ./stream
as opposed to just using the value returned.
If v2 has the foo service as above over http what do we add to the record?
My idea was that if you speak vX of Signal K you know where to go from the root.
Btw I'm good with your choice as well, as full urls make sense. If you choose to go that way we need to update doc, node server and test client as well.
I like the full urls too. Lets go with that. @jboynes - re the /signalk prefix keep in mind it may be deployed as a war file, so it may get /signalk from the web context...
I did not see a schema for this resource so added one in specification #148.
What's the status of this? Freshly pulled signalk-java-server returns
{
"endpoints": {
"signalk-tcp": "tcp://192-168-1-115.local.:55555",
"signalk-udp": "udp://192-168-1-115.local.:55554",
"nmea-tcp": "tcp://192-168-1-115.local.:55557",
"nmea-udp": "udp://192-168-1-115.local.:55556",
"signalk-http": "http://192-168-1-115.local.:8080/signalk/v1/api/",
"mqtt": "mqtt://192-168-1-115.local.:1883",
"signalk-ws": "ws://192-168-1-115.local.:3000/signalk/v1/stream",
"stomp": "stomp+nio://192-168-1-115.local.:61613"
}
}
I am adjusting testclient
to support http and ws in different ports by connecting to http first to get the endpoints so this is kinda blocking that effort.
I will update tonite
Done - just git pull, and it should be right now - close this if so?
Verified, working.
Java server is reporting the host as localhost
, which isn't really useful:
{
"endpoints": {
"0.": {
"signalk-tcp": "tcp://localhost:55555",
"signalk-udp": "udp://localhost:55554",
"nmea-tcp": "tcp://localhost:55557",
"nmea-udp": "udp://localhost:55556",
"signalk-http": "http://localhost:8080/signalk/v1/api/",
"mqtt": "mqtt://localhost:1883",
"signalk-ws": "ws://localhost:3000/signalk/v1/stream",
"stomp": "stomp+nio://localhost:61613",
"version": ".1"
}
}
}
It reports whatever host was specified in the HTTP request:
$ curl "http://localhost:8080/signalk"
{"endpoints":{"v1":{"signalk-tcp":"tcp://localhost:55555","signalk-udp":"udp://localhost:55554","nmea-tcp":"tcp://localhost:55557","nmea-udp":"udp://localhost:55556","signalk-http":"http://localhost:8080/signalk/v1/api/","mqtt":"mqtt://localhost:1883","signalk-ws":"ws://localhost:3000/signalk/v1/stream","stomp":"stomp+nio://localhost:61613","version":"1.0.0"}}}
$ curl "http://Jeremys-iMac.local:8080/signalk"
{"endpoints":{"v1":{"signalk-tcp":"tcp://Jeremys-iMac.local:55555","signalk-udp":"udp://Jeremys-iMac.local:55554","nmea-tcp":"tcp://Jeremys-iMac.local:55557","nmea-udp":"udp://Jeremys-iMac.local:55556","signalk-http":"http://Jeremys-iMac.local:8080/signalk/v1/api/","mqtt":"mqtt://Jeremys-iMac.local:1883","signalk-ws":"ws://Jeremys-iMac.local:3000/signalk/v1/stream","stomp":"stomp+nio://Jeremys-iMac.local:61613","version":"1.0.0"}}}
@tkurki
{
"endpoints": {
"0.": {
there is a version key in the signalk-conf.json - it should be 'v1.x.x' now. Rather crudely the first two chars are used for the 'v1':{..}
key, and the the substring(1,length) used for the version
field.
Needs a better method really, but ok for now.
Closing as this all works now
http://signalk.org/developers/apis_and_conventions.html specifies a way to discover a server's supported SK versions and endpoints:
/signalk
should return a response like