POST as addition to transport protocol methods

[UlfBj]

The current VISS ver 2 spec makes use of the URL query syntax to augment the GET method. This can lead to somewhat unreadable URLs. After my latest attempt to add yet another query, this time allowing the client to express multiple paths to random nodes in the tree, Adnan proposed that maybe this could be done by using POST together with the query expression in the payload instead, to get more readable URLs. I think that is an excellent idea, so I would like to propose that all current queries that are defined in the spec are transformed into POST plus JSON payloads instead. The mentioned path query, which I exemplified with GET Vehicle.Powertrain.BatteryManagement.Battery.AccumulatedChargeEnergy$pathsEQ[Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Latitude, Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Longitude] would transform into POST Vehicle.Powertrain.BatteryManagement.Battery.AccumulatedChargeEnergy {"paths":[Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Latitude, Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Longitude]}

The new method would be used in both HTTP and Websocket protocols.

[petervolvowinz]

I think that with POST - at least for HTTP - the general idea is to send data to a server to create/update a resource and not as in this case retrieving data. Or ?

[UlfBj]

I think that with POST - at least for HTTP - the general idea is to send data to a server to create/update a resource and not as in this case retrieving data. Or ?

It might be the general idea, but reading RFC2616, it seems not be the only acceptable idea.

Chapter 4.3 Message body: The rules for when a message-body is allowed in a message differ for requests and responses.

The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1). All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity- header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length.

Chapter 7 Entity: Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.

Chapter 7.2 Entity Body: 7.2 Entity Body

The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.

   entity-body    = *OCTET

An entity-body is only present in a message when a message-body is present, as described in section 4.3. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of the message.

[tguild]

https://www.w3.org/2020/11/03-auto-minutes.html see Adnan's suggestion

GET /multiplePoints?json={"paths":[Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Latitude, Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Longitude]}

[adobekan]

copy from chat. @UlfBj

In case of HTTP. GET /multiplePaths?json={"paths":[Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Latitude, Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Longitude, ...]} It can be also POST, as invoking multiplePaths function. But we have to add e.g. multiplePaths in specification that will be part of interface.

filter example: GET /vehicle/Cabin?json={"leafs":[Latitude, Longitude]}

or Just simply select suitable technology and say with WS we can deliver multiple points from various branches, while HTTP could be used for single points or multiple points in one single branch.

example: If leafs are in a same branch, you can request Latitude and Longitude with following request. GET /Vehicle/Cabin/Infotainment/Navigation/CurrentLocation/

[UlfBj]

My view of the WG discussion yesterday is that we decided not to go with using POST and payload, but to stay with GET and query. This was exemplified with the proposal for support of multiple paths in the same request, where the URL would be the path to a common root node for the requested paths, and then the query would include the relative paths from this root node, as exemplified below (I have changed json to filter)

GET /Vehicle?filter={"paths":[Powertrain.BatteryManagement.Battery.AccumulatedChargeEnergy, Cabin.Infotainment.Navigation.CurrentLocation.Latitude, Cabin.Infotainment.Navigation.CurrentLocation.Longitude]}

The discussion touched upon whether the wildcard paradigm should be supported. My view on that is that it should be supported, both through the possibility to replace a path segment by the star character (*) ,and by terminating the path on a branch (in which case the entire sub tree below is addressed). With this latter option the example above could be reduced to

GET /Vehicle?filter={"paths":[Powertrain.BatteryManagement.Battery.AccumulatedChargeEnergy, Cabin.Infotainment.Navigation.CurrentLocation]}

Support for the wildcard concept would enable the merging of this query, and the "search" query that is in the spec already. I think this "query pattern"

GET /path-exp?filter=json-formatted-filter-expression

should also be applied to all existing queries in the spec. For the Websocket protocol this would translate into the following payload

{"action":"get", "path":"path-exp", "filter":"json-formatted-filter-expression"}

which I think leads to a consistent uniformity over queries and transport protocols.

[tguild]

https://github.com/w3c/automotive/issues/350 see PR

[UlfBj]

The discussions on this issue led to the the query pattern in the thread above, implemented in PR#350