Closed sbender9 closed 5 years ago
I think this needs some changes.
correlationId
should be requestId
.
When processing an incoming message its easy to look for update
,put
, subscribe
etc in the body and process that accordingly.
The format here means thats more complex, having to look at the requestId and decide if its a reply etc.
I would use something like:
PUT Request
{
"context": "vessels.self",
"requestId": "184743-434373-348483",
"put": {
"path": "steering.autopilot.target.headingTrue",
"source": "actisense.204",
"value": 1.52
}
}
Response
{
"context" : "vessels.self",
"requestId": "184743-434373-348483",
"state": "COMPLETED"
"result" : 200
"message|percentComplete|etc"
}
The client should already know what they requested, and any changes will have been propagated by updates any way, in fact the following should be valid too (it is in artemis):
{
"context": "vessels.self",
"requestId": "184743-434373-348483",
"state": "COMPLETED",
"result": 200,
"updates": [{
"timestamp": "2013-10-08T15:47:28.263Z",
"source": "actisense.204",
"values": [{
"path": "steering.autopilot.target.headingTrue",
"value": 1.52
}]
}]
}
@rob42 agreed. I removed the details about the put request from the response.
See my notes on https://github.com/SignalK/specification/pull/508
Unless there are an objections, I think this is ready to go.
See https://github.com/SignalK/specification/issues/442 for past discussions on this.
This, like #506 and #505, this brings up the requirement to define the semantics for request/response over WS and other non HTTP protocols. See #508
TODO