Create or update a thing with a specified ID
Create or update the thing specified by the thingId path parameter and the optional JSON body.
- If you set a new
thingIdin the path, a thing will be created. - If you set an existing
thingIdin the path, the thing will be updated.
Create a new thing
At the initial creation of a thing, only a valid thingId is required.
However, you can create a full-fledged thing all at once.
Example:
To create a coffee maker thing, set the thingId in the path, e.g. to "com.acme.coffeemaker:BE-42"
and the body part, like in the following snippet.
{
"definition": "com.acme:coffeebrewer:0.1.0",
"attributes": {
"manufacturer": "ACME demo corp.",
"location": "Berlin, main floor",
"serialno": "42",
"model": "Speaking coffee machine"
},
"features": {
"coffee-brewer": {
"definition": [ "com.acme:coffeebrewer:0.1.0" ],
"properties": {
"brewed-coffees": 0
}
},
"water-tank": {
"properties": {
"configuration": {
"smartMode": true,
"brewingTemp": 87,
"tempToHold": 44,
"timeoutSeconds": 6000
},
"status": {
"waterAmount": 731,
"temperature": 44
}
}
}
}
}As the example does not set a policy in the request body, but the thing concept requires one, the service will create a default policy. The default policy, has the exactly same id as the thing, and grants ALL permissions to the authorized subject.
In case you need to associate the new thing to an already existing policy you can additionally set a policy e.g. "policyId": "com.acme.coffeemaker:policy-1" as the first element in the body part. Keep in mind, that you can also change the assignment to another policy anytime, with a request on the sub-resource "PUT /things/{thingId}/policyId"
The field _created is filled automatically with the timestamp of the creation. The field is read-only and can
be retrieved later by explicitly selecting it or used in search filters.
Update an existing thing
For updating an existing thing, the authorized subject needs WRITE permission on the thing's root resource.
The ID of a thing cannot be changed after creation. Any thingId
specified in the request body is therefore ignored.
Body
JSON representation of the thing to be modified.
_ policyPolicyThe initial policy to create for this thing. This will create a separate policy entity managed by resource /policies/{thingId}.
Use the placeholder {{ request:subjectId }} in order to let the backend insert the authenticated subjectId of the HTTP request.
_ copyPolicyFromstringThis field may contain
the policy ID of an existing policy.
The policy is copied and used for this newly created thing. The caller needs to have READ and WRITE* access to the policy.
a placeholder reference to a thing in the format {{ ref:things/[thingId]/policyId }} where you need to replace [thingId] with a valid thing ID.
The newly created thing will then obtain a copy of the policy of the referenced thing. The caller needs to have READ access to the thing and READ and WRITE* access to the policy of the thing.
* The check for WRITE permission avoids locking yourself out of the newly created policy. You can
bypass this check by setting the header allowPolicyLockout to true. Be aware that the authorized
subject cannot modify the policy if you do not assign WRITE permission on the policy resource!
If you want to specify a policy ID for the copied policy, use the policyId field.
This field must not be used together with the field _policy. If you specify both _policy and _copyPolicyFrom this will lead to an error response.
policyIdstringrequiredThe policy ID used for controlling access to this thing. Managed by
resource /policies/{policyId}.
definitionDefinitionA single fully qualified identifier of a definition in the form '::' or a valid HTTP(s) URL
attributesAttributesAn arbitrary JSON object describing the attributes of a thing.
featuresFeaturesList of features where the key represents the featureId of each feature.
The featureId key must be unique in the list.
Parameters
thingIdstringrequiredpathThe ID of a thing needs to follow the namespaced entity ID notation (see Ditto documentation on namespaced entity IDs).
If-MatchstringheaderThe If-Match header, which has to conform to RFC-7232 (Conditional Requests). Common usages are:
- optimistic locking by specifying the
ETagfrom a previous GET response, e.g.If-Match: "rev:4711" - retrieving or modifying a resource only if it already exists, e.g.
If-Match: *
If-None-MatchstringheaderThe If-None-Match header, which has to conform to RFC-7232 (Conditional Requests). A common usage scenario is to modify a resource only if it does not yet exist, thus to create it, by specifying If-None-Match: *.
if-equalstringupdateskipskip-minimizing-mergeheaderThe if-equal header can take the values 'update' (which is the default if omitted), 'skip' or 'skip-minimizing-merge'. If 'update' is defined, the entity will always be updated, even if it is equal before the update. If 'skip' is defined, the entity not be updated if it is equal before the update. In this case a 'Precondition Failed' 412 status is returned. If 'skip-minimizing-merge' is defined, the entity will not be updated if it is equal before the update. In this case a 'Precondition Failed' 412 status is returned. Additionally, merge/patch commands will be minimized to only the fields which actually changed, compared to the current state of the entity.
put-metadataArray<object>headerThe put-metadata header, which sets Metadata information in the Thing.
delete-metadatastringheaderThe delete-metadata header, which deletes Metadata of the Thing.
requested-acksstringqueryContains the "requested acknowledgements" for this modifying request as comma separated list. The HTTP call will
block until all requested acknowledgements were aggregated or will time out based on the specified timeout
parameter.
The default (if omitted) requested acks is requested-acks=twin-persisted which will block the
HTTP call until the change was persited to the twin.
timeoutstringqueryDefines how long the backend should wait for completion of the request, e.g. applied when waiting for requested
acknowledgements via the requested-acks param. Can be specified without unit (then seconds are assumed) or
together with s, ms or m unit. Example: 42s, 1m.
The default (if omitted) and maximum timeout is 60s. A value of 0 applies fire and forget semantics for
the command resulting in setting response-required=false.
response-requiredbooleanqueryDefines whether a response is required to the API call or not - if set to false the response will directly
sent back with a status code of 202 (Accepted).
The default (if ommited) response is true.
conditionstringqueryDefines that the request should only be processed if the given condition is met. The condition can be specified using RQL syntax.
Examples
E.g. if the temperature is not 23.9 update it to 23.9:
PUT /api/2/things/{thingId}/features/temperature/properties/value?condition=ne(features/temperature/properties/value,23.9)body: 23.9
Further example conditions:
?condition=eq(features/temperature/properties/unit,"Celsius")?condition=ge(features/temperature/properties/lastModified,"2021-08-22T19:45:00Z")?condition=gt(_modified,"2021-08-05T12:17:00Z")?condition=exists(features/temperature/properties/value)?condition=empty(features/temperature/properties/value)?condition=and(gt(features/temperature/properties/value,18.5),lt(features/temperature/properties/value,25.2))?condition=or(gt(features/temperature/properties/value,18.5),not(exists(features/temperature/properties/value))
channelstringtwinlivequeryDefines to which channel to route the command: twin (digital twin) or live (the device).
- If setting the channel parameter is omitted, the
twinchannel is set by default and the command is routed to the persisted representation of a thing in Eclipse Ditto. - When using the
livechannel, the command/message is sent towards the device.
Response
The thing was successfully created.
The thing was successfully modified.
The request could not be completed. Possible reasons:
- the
thingIddoes not conform to the namespaced entity ID notation (see Ditto documentation on namespaced entity IDs) - the JSON body of the thing to be created/modified is invalid
- the JSON body of the thing to be created/modified contains a
thingIdwhich does not match the ID in the path
The request could not be completed due to missing authentication.
The request could not be completed. Possible reasons:
- the caller would not have access to the thing after creating it with the given policy
- the caller has insufficient permissions.
For modifying an existing thing, an unrestricted
WRITEpermission on the thing's root resource is required.
The request could not be completed. Possible reasons:
- the referenced thing does not exist.
- the caller has insufficient permissions to read the referenced thing.
- the policy that should be copied does not exist.
- the caller has insufficient permissions to read the policy that should be copied.
A precondition for reading or writing the (sub-)resource failed. This will happen for write requests, if you specified an If-Match or If-None-Match header, which fails the precondition check against the current ETag of the (sub-)resource. For read requests, this error may only happen for a failing If-Match header. In case of a failing If-None-Match header for a read request, status 304 will be returned instead.
The created or modified entity is larger than the accepted limit of 100 kB.
One or more acknowledgement requests in the parameter requested-acks
were not fulfilled.
Authorization
OpenIDConnectopenIdConnectOpenID Connect Discovery URL. The placeholder is replaced by Swagger UI when configured.
NginxBasichttp (basic)Eclipse Ditto sandbox demo user (demo1 ... demo9) + password (demo)
Bearerhttp (bearer)A JSON Web Token issued by a supported OAuth 2.0 Identity Provider.