feature: PUT Requests

[sbender9]

See #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

• sync up with feature: define request reponse semantics #508

[rob42]

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
		}]
	}]
}

[sbender9]

@rob42 agreed. I removed the details about the put request from the response.

[fabdrol]

See my notes on #508

[sbender9]

Unless there are an objections, I think this is ready to go.