Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[hono-dev] Redundant(?) properties in API messages

Hi all,

 

Kai and I are having a Hono “hackathon” this week and we were just reflecting on how we transport information required for routing and authorization decisions. This is currently the name of the endpoint (e.g. telemetry, control, registration, …), the tenant-id and the device-id. Now this data is scattered across several fields in a message (link’s source/target address, the to property, tenant-id header, device-id header) which is redundant and might be confusing to a user. So one suggestion would be to have this information in a single field and extract relevant data from there and add headers for routing in the backend where required.

Example: For telemetry upload, the single source of information would be the to property of a message: /telemetry/${tenant-id}/${device-id}. There would be no more tenant-id or device-id header in the message received from clients, but if we need the information in a separate header e.g. for routing, we can add this in our Hono service.

 

This way we would have less redundancy and less confusion. This would also play nicely with an authorization based on these resources e.g. to allow upload of telemetry data for ${device-id} which belongs to ${tenant-id}, you would give permission WRITE on resource /telemetry/${tenant-id}/${device-id}. Same would apply for telemetry consumption (READ on resource /telemetry/${tenant-id}) etc.

 

What do you think?

 

Best regards

 

Dominik Guggemos

INST/ECS1

 

Tel. +49 7545 202-396

www.blog.bosch-si.com

 


Back to the top