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

Hi Zoltan,

Regarding REST API and Scripting API: we had a Babylonian confusion everytime somebody said API. - Do they mean the scripting API or the Web-API/REST-API/Protocol Binding? 
IMHO we always have been targeting to define a "narrow-waist" model (events, properties, actions, ...)and serialize it (as the TD), access it from scripts and map it to resources so we can define REST-bindings and easily adopt to various protocols by mapping the REST primitives.

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.
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).

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 .

This will work with both "Greenfield" and "brownfield" cases

Best regards,
Johannes

Received on Friday, 9 December 2016 12:17:40 UTC