Expose the software service through the HTTP/JSON API

[imobachgs]

Trello: https://trello.com/c/2MjaulMd/3566-3-expose-the-software-api-over-http

This PR exposes the public¹ part of the software API through the HTTP/JSON interface. It includes:

• /software/patterns: list of patterns, including whether they are selected (and by whom).
• /software/products: list of products.
• /software/probe: starts the software probing.
• /software/config: describing the software configuration.

{
  "patterns": [
    "gnome"
  ],
  "product": "Tumbleweed"
}

Additionally, it exposes the following events through the websocket:

• PatternsChanged, containing the patterns and who selected them ('user' or 'auto').
• ProductChanged, with the name of the new product.

Implementation details

In this phase of the development, we are still deciding the best way to implement these HTTP/JSON interfaces. The implementation has two parts:

• The HTTP/JSON interface itself, which is implemented as a Router and a set of small functions (one per each endpoing+verb).
• An events stream which emits Event values (see stream in the Tokio documentation).

About the service status, the zbus proxies are cached and can be cloned, so it looks like a good idea to keep our clients as part of the state.

In the future

There are a few improvements we could consider in the future:

• Split the events in different types depending on the service (SoftwareEvent, ManagerEvent), so those services only know about their types.
• Consolidate all errors under a common one (e.g., Error::Software(SoftwareError), Error::Manager(ManagerError), etc.) to have a single IntoResponse implementation while keeping modules isolation.

Footnotes

1. The part of the D-Bus API that it is used by the web UI. ↩

[coveralls]

coverage: 74.401% (-0.3%) from 74.665%
when pulling 4c0cb3b on http-software-srv
into 3392064 on master.

[jreidinger]

Can it happen that change result is not Ok? And if so, in which case? I would at least document it here.

[imobachgs]

If it fails, it is because it cannot deserialize the information coming from D-Bus. Our proxy could be outdated, for instance. But I do not think we should put a comment about that in each place where we use this function.

See https://docs.rs/zbus/latest/src/zbus/proxy/mod.rs.html#196-200 (because get documentation) is not enough.

In general, any conversion problem is, most probably, because our proxies are outdated.

[jreidinger]

ok, so basically internal problem and not user side.

[jreidinger]

now, I am confused, why is not there 2 => Ok(Self::None)

[imobachgs]

Because it is not expected to get a 2 from the API (it does not exist).

[jreidinger]

ah, ok.