Set PATCH or POST requests as blocking or nonblocking

In a blocking request, which is the default, the action described by the payload is validated. The, the request is completed with the resultant HTTP response code to indicate success or failure. Success is indicated by a 200 – OK return code, and failure is indicated by the most appropriate HTTP return codes.

To make a request nonblocking, use the "options" section of the JSON payload for an action. In the following sample, which uses the /probe/common PATCH example data to create a new property, an "options" section is added, which specifies the extra JSON data.

{
	"options":	{"block_response" : false },
	"properties":	{
			"MyNewProperty" : "myvalue"
	}
}

After this request is syntactically and semantically validated, the HTTP server responds with a 202 – Accepted response code. At this point, the action is requested, but not executed.

If an invalid request is made, which includes the nonblocking flag, a failure HTTP response code is returned. The following example would return a 400 – BAD REQUEST response code, because the new property value is not a string. Each new property that is created must have a string value.

{
	"options" : 	{ 
		"block_response" : false },
		"properties":	{
			"MyNewProperty": 1
		}
}

Nonblocking requests that are accepted (by using { "block_response" : false }) can still fail due to internal unforeseen problems. Because the HTTP connection is effectively closed, the HTTP interface cannot inform the client of any subsequent problems. For this reason, an optional acknowledgement event can be generated by the HTTP interface for such requests.