Re: [hono-dev] Redundant(?) properties in API messages

[Gordon Sim <gsim@xxxxxxxxxx>]

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.