Skip to main content

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

On 26/04/16 12:45, Guggemos Dominik (INST/ECS1) wrote:
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?

Sounds reasonable to me.



Back to the top