Re: Capabilities & Schemas

On 16 May 2018 at 03:57, Michael Koster <michael.koster@smartthings.com>
wrote:

> Currently, we are biased toward flexibility and not having mandatory
> compositions. We expect the documents that carry the annotation to be
> self-describing and clients to be able to adapt to what is offered. This is
> borrowing from a fundamental REST and Hypermedia design style.
>
> It is an interesting tradeoff to discuss, as there is admittedly more work
> in making a client that adapts. This can be traded off against the long
> term benefit of less coupling between server and client, making them
> separately evolveable. This is a benefit which accrues over time, where the
> cost of client adaptation must be paid up front.
>
> What do you think? What are the constraints of your economic analysis that
> motivate one design style versus the other?
>

The main constraint is a requirement for ad-hoc interoperability and the
feasibility of implementing a client which is adaptable enough to variation
in data representation.

It's true that REST allows complete flexibility in data representation, but
in practice that also usually requires a client implementation per API. By
defining a Thing Description format with its own MIME type and a set of
schemas which specify data constraints for a shared repository of
capabilities, we hope to enable ad-hoc interoperability such that a client
which implements support for those schemas can consume any Thing which
implements that schema, without modification. Otherwise, what have we
gained over the current situation where every IoT cloud service provides
its own incompatible REST API?

Ben