AW: New REST API support in w3c-visserver-api

Hi ,

Thank you Bojan! Please keep in mind we did this as an implementation “in the spirit” of W3C. Whenever something is different from the spec (especially current discussions, which we maybe did not follow as closely as we should, and probably there was some parallel work) it is (probably ☺ ) not intended as a suggestion to change the spec.

We just needed something to play, we are not married to technical details. So in case some of you who are more deeply involved here try playing and spot something where you think why is x missing, why you did y differently we would like to hear it.

And of course, as Bojan mentioned, we do like e-mails, but we do like pull requests even more.

Mit freundlichen Grüßen / Best Regards

Sebastian Schildt
CR/AEX1
Threema<threema://add/?id=T8YWYXJ9> / Threema Work<threemawork://add/?id=T8YWYXJ9>: T8YWYXJ9

Von: FIXED-TERM Miladinovic Bojan (RBSN/ESW22) <fixed-term.Bojan.Miladinovic@se.bosch.com>
Gesendet: Dienstag, 26. November 2019 12:54
An: public-automotive@w3.org
Betreff: New REST API support in w3c-visserver-api

Hi all,

I would like to announce experimental REST API support as a new feature of w3c-visserver-api.

Feature is already merged and available in w3c-visserver-api<%20https:/github.com/eclipse/kuksa.invehicle/tree/master/w3c-visserver-api> git repo with an updated README.md<https://github.com/eclipse/kuksa.invehicle/blob/master/w3c-visserver-api/README.md> with more details.

In short:

  *   Both Web-Socket and REST are supported at the same time. Extending/improving of REST API support is fairly straight-forward as REST API handler generates valid JSON requests toward single lower-level handler.


  *   Depending on server security configuration, both Web-Socket and REST can use both plain and TLS protected connection.


  *   Existing support for get/set/getmetadata/authorize requests is fully mimicked to match current implementation and its limitations. Any limitations (e.g. setting of multiple signals in single request, complex queries, ...) are currently not supported on both Web-Socket and REST API. Due to this, any data sent in REST request body is ignored (e.g. json data).


  *   'subscribe/unsubscribe'  requests are not supported, due to default natural flow of REST client -> server HTTP communication. If needed, support for them could be added in the future, but with some 'stretching' of regular HTTP connection flow.


·       Initial REST API documentation is provided in open-source 'OpenAPI' 3.0.1 format. Additional benefit of 'OpenAPI' format is posibility of automatic generation of interactive documentation direcly exercising defined REST API. Depending on tool used, both test client and server can be automatically generated. File rest-api.yaml<https://github.com/eclipse/kuksa.invehicle/blob/master/w3c-visserver-api/doc/rest-api.yaml> describes currently implemented REST API. How to use is described in this chapter<https://github.com/eclipse/kuksa.invehicle/tree/master/w3c-visserver-api#rest-api-specific-testing> of README.md.


Example for both features active at the same time could be found in use-case where more complex 'feeders' use Web-Socket connections to populate data, while 'thin' clients can get data through REST API from the server without the need to maintain Web-Socket connection.

Please be free to take a look and play with the current implementation.
Any comments and pull requests are highly welcome.


All the best,
Bojan