API update devices using PUT request

We’ve been trying to update some device parameters (name, applicationID, description, tags, variables) in bulk using the PUT devices request on the API. For context this will be very helpful for us as we need to update the tags and variables of almost 1000 devices.

What we have found is that if some of the device parameters were configured already but are missing on the PUT request JSON, these are deleted. For example:

Device created:
{
“device”: {
"applicationID": “3”,
“description”: “this is a description”,
“devEUI”: “5566b2330cf30bd7”,
“deviceProfileID”: “0d9882e9-c593-4ad1-a7a9-7cf70a43785b”,
“isDisabled”: true,
“name”: “this_is_just_a_test”,
“referenceAltitude”: 1000,
“skipFCntCheck”: true,
“tags”: {“first”: “this is a first tag”, “second”: “this is a second tag”},
“variables”: {“first”: “this is a first var”, “second”: “this is a second var”}
}
}
JSON on the put request:
{
“device”: {
“devEUI”: “5566b2330cf30bd7”,
“deviceProfileID”: “0d9882e9-c593-4ad1-a7a9-7cf70a43785b”,
"applicationID": "4"
}
}

After using the PUT request, this is what can be seen on ChirpStack:


The name and description have been removed, as well as the tags and variables.

Is this expected behavior? Of course this can fixed using first a GET devices request to get the full device JSON, work on top of it and then use the PUT request to update that device, but this can be time consuming.

Thanks in advance for any help :smiley:

Yes it is the expected behavior.

A PATCH request is considered a set of instructions on how to modify a resource. Contrast this with PUT; which is a complete representation of a resource.

2 Likes

This. Note that the ChirpStack AS does not support PATCH at this time.

Hello @brocaar We would like to have the option to use PATCH requests for devices on the API. Would you accept a merge request to ChirpStack AS if we develop this functionality and it meets your standards?

1 Like

I’m not sure if it is worth the complexity (also in terms or maintenance) as it would touch all update related API methods.

Note that the REST API is provided on top of the gRPC API using the gRPC gateway (GitHub - grpc-ecosystem/grpc-gateway: gRPC to JSON proxy generator following the gRPC HTTP spec</title). While the REST API is maybe more convenient, I would recommend using the gRPC interface instead. It removes one layer of translation (as internally REST calls are transformed to gRPC calls), but it also gives you client implementations for free for several programming languages.

Historically, I added the gRPC gateway to make it possible to integrate the web-interface with the gRPC based API methods as grpc-web (GitHub - grpc/grpc-web: gRPC for Web Clients) didn’t exist at that point.