Messages resources

Messages can be used to transport arbitrary data between IoT devices and applications.

To invoke e.g. an operation on a device, a message can be sent to the thing or one of its features.
You can send messages to or from a thing by specifying a subject which defines the meaning of the message. Messages contain custom payload with a custom content-type.

A message does not directly affect the state of a thing entity, but needs to be handled respectively by your device or application.
See Messages.

Example: From an application's perspective, a message can be sent to a thing or one of its features to call e.g. an operation at a device.

Messages do not affect the state of a thing entity or a device. Therefore, Bosch IoT Things does not handle messages like commands: there are no responses which are produced by our service and no events which are emitted for messages. Instead, the message needs to be handled respectively by your solution.


 

There is no root resource for Messages as they are always related to a Thing.

The following operations are available over the HTTP API:

Note on messageSubject:
Due to the fact that a Message Subject might need to be set in the path, we have restricted the set of allowed characters to those for Uniform Resource Identifiers (URI) see http://www.ietf.org/rfc/rfc2396.txt.

Bosch IoT Things provides a HTTP API for claiming to enable end-users to claim Things and proof ownership thereof.

By posting to a Thing's claim resource, our service sends a claim message to the Thing. The request may contain an arbitrary body and content-type to allow Thing-specific implementation of the actual claiming. The claiming will not be terminated or evaluated at our service, therefore the decision whether to grant access (by setting permissions) is completely up to the client(s) which handle the claim message.

Find details at Claiming.

To prevent brute-force attacks, the Bosch IoT Things service implements rate limiting and defines a default timeout for all requests at the HTTP API.

All sub-resources for Messages provide an optional timeout parameter. The value defines the time (in seconds) how long to block the HTTP request and wait for a response.

  • Default value (if omitted): 60 seconds
  • Maximum value: 600 seconds
  • Minimum value: 0 seconds (i.e. fire-and-forget)

As a result the Messages resources now support the request-response pattern as well as fire-and-forget semantics.