- From: Jonas Schmidt <jos89@gmx.de>
- Date: Tue, 13 Jun 2017 10:20:25 +0200
- To: Gunnar Andersson <gandersson@genivi.org>
- Cc: public-autowebplatform@w3.org, PHILIPPE COLLIOT <philippe.colliot@mpsa.com>
- Message-ID: <CAHChMiepNkKDAjR=x4O-CPORWPHUP7msSpC3T=52cj=znWmXeg@mail.gmail.com>
Hi Gunnar, > But that's assuming that the REST architecture pattern fits into an > automotive environment... > ;-) I'm just kidding - it's a good thesis subject, I'm sure. I hope so. :D > So you used the use-cases but not the GENIVI LBS APIs? It seems an > unnecessary reinvention to not reuse the names of properties and such that > many others are used to? Also if you did, it would be easier to draw the > interesting thesis conclusions in my opinion (see below). Actually I used the terms described in the single descriptions of the use cases and the names of the functions mentioned in the right column of https://at.projects.genivi.org/wiki/display/NAV/IVI+NavigationW3CUseCasesAndGENIVIAPIs But I am open for any suggestions concerning the naming of the properties. > What were the assumptions going into your project that made you do it that > way? I wanted to create micro services that are "as restful as" possible. I tried to include concepts like separation of concerns etc. My proposal is just a first draft so as I sad I'm open for any suggestions. > This is good and similar to what GENIVI has been looking at in this area > too. Essentially we are interested in investigating the result of taking a > comprehensive LBS API that has been published, most of which are of Remote- > Procedure-Call + Signal type... I think you're talking about the xml api specification of the GENIVI API which you want to use for api generation. (did I get this right) To be honest: I did not examined the xml yet. Kind regards, Jonas 2017-06-06 11:45 GMT+02:00 Gunnar Andersson <gandersson@genivi.org>: > On Sat, 2017-06-03 at 09:36 +0200, J. Schmidt wrote: > > Hi Everybody, > > Hello Jonas > > > > > My name is Jonas Schmidt (germany). I’m currently doing my bachelor’s > > degree in business informatics. I wanted to build an interface > > specification for my thesis based on the REST architecture pattern that > > fits into an automotive environment. > > But that's assuming that the REST architecture pattern fits into an > automotive environment... > ;-) I'm just kidding - it's a good thesis subject, I'm sure. > > > > > After some research I recognized the submission of (i.a.) Dr.. Patrick > > Bartsch that is public on W3C and found the github account and confluence > > pages of GENIVI Alliance. They attracted my attention while I searched > use > > cases for some connectivity projects for cars. I took the GENIVI use > cases > > and specified an interface based on the viwi protocol submission. > > So you used the use-cases but not the GENIVI LBS APIs? It seems an > unnecessary reinvention to not reuse the names of properties and such that > many others are used to? Also if you did, it would be easier to draw the > interesting thesis conclusions in my opinion (see below). > > What were the assumptions going into your project that made you do it that > way? > > > Now I want to examine the differences between imperative/stateful and > > stateless approaches while specification and implementation phase. > > This is good and similar to what GENIVI has been looking at in this area > too. Essentially we are interested in investigating the result of taking a > comprehensive LBS API that has been published, most of which are of Remote- > Procedure-Call + Signal type, and looking at the results of a fully- or > semi-automated conversion to a REST interface. If you also tried that and > evaluated the result then I think you would get good answers to the > question > at hand here. > > In general there should be no reason to start from scratch when going to a > new domain like Web APIs. I believe strongly in the idea that the essence > of APIs should as much as possible be defined once - not uniquely for > different domains. But that may need a bit more investigation so I'm > looking forward to hear your results if you investigate that aspect in > particular (as opposed to just writing a brand new API). > > On the details of that, I haven't looked too deeply at how much client-side > state is assumed in the GENIVI LBS APIs today, but I would not imagine it > can be that much. Most of the time you either want to get the latest value > of some property, or just perform an operation or otherwise affect > something > on the receiver (server) side. > > > > > Patrick asked me if I want to publish my proposal and participate to the > > BG. So here I am. > > > > You can find my proposal on > > github: https://github.com/j3ss5t/viwiLocationBasedServices > > > > Best regards > > > > Jonas > > Best Regards > - Gunnar > > -- > Gunnar Andersson <gandersson@genivi.org> > Development Lead > GENIVI Alliance > > > >
Received on Tuesday, 13 June 2017 09:12:53 UTC