Re: [Charter]: include both Scripting and REST API

Hi Johannes,

It seems we've cross-posted in the issue #288 and here :).

On Fri, Dec 9, 2016 at 2:17 PM, Hund, Johannes <johannes.hund@siemens.com>
wrote:

>
> I think the question in the room is how to map the model to RESTful
> resources and if you can do it vice versa ?
>
> One approach is to define how the uris should look like plus what payloads
> are expected and returned etc. as it is done in the submission from
> COMPOSE/EVERYTHNG.
>
> I like the approach of the submission and see the value, specifically if
> you have a green field, you know exact and concrete how to design your
> resources.
>

Yes, this was the case.



> I think we might need more that this (adding to it and complementing), if
> we want to use the approach also for the "brown field", such as  existing
> REST APIs, devices, silos, other standards such as OCF etc.
> Specifically, I would avoid to hardcode the uri templates in the client.
>
> My suggestion would be to have a way to provide links between the uris and
> define a handful of relations you need to know (action, property,...), as
> it is done with the HATEOAS principle.
> Then we can use thing description as a point where you find all links,
> like an equivalent to "index.html" (or e.g.  the directory listing index
> from apache).
>

This needs some thought and formulation with examples.


>
> The delta to the current form is in my opinion:
> - No hard requirement of HTTP, but a focus on defining resource structure
> and payloads, like OCF did with CRUDN + types etc. That way we can use also
> use e.g. CoAP etc.
> - specify a way to express links (e.g. based on are approaches like HAL or
> JSON hyperschema)
> - We need a way to provide a link list/map that allow the client to use
> existing resource structures using the same model , e.g. if there is a REST
> API that cannot be changed (legacy or a domain standard) - this could be
> the TD
>
> This still keeps the client very straightforward, it just has to get a
> link from the data by its relation type and use .
>

I agree. The issues you mentioned should be solved - I just wasn't sure
where this work is done, whether it is being done, and whether the charter
allows that at all. I've seen the past contributions without being
reflected upon nowadays. Based on comments from Matthias, I think I
understand that better now.

On a separate note I'd like to mention that I understand the separation of
WoT from the underlying protocols is not very simple in many cases,
especially when various security models and policies, network architectures
and policies, provisioning and on-boarding mechanisms, tailored cache
solutions etc start playing. Rather, I see it that way that WoT should be
easy to be supported by those solutions. And it is correct that TD is the
common denominator and the key player there. In my view having RESTful
interactions between WoT Things is possible exactly because the underlying
architectures will make it possible by supporting WoT. Without being
provisioned for, and without being able to generate a TD from the
underlying representations, WoT Things won't have a chance to work with OCF
resources for instance, and OCF devices/resources won't be able to act as
Things. Even then, WoT Things are expected to play by the rules defined in
the "native" networks and solutions. I guess that is one of the reasons the
group may be reluctant to work on an explicit REST API. However, having
some insight in how other groups work, this should be matter of cooperation
and for that we do need to run the full circle and make explicit use cases,
specifications and recommendations on how do we solve the use cases by
interacting how between Things.

Best regards,
Zoltan