Update documentation

Author: joseivanlopez

doc/http_api.md

@@ -20,18 +20,20 @@ The API is designed around 3 main concepts: *system*, *config* and *proposal*.
 The *config* contains elements that can modify the *system*, the *proposal* or both. For example, the *dasd* config changes the *system*, and the *storage* config changes the *proposal*. In other cases like *network*, the config can affect to both *system* and *proposal*.
 
 ~~~
+GET             /status
 GET             /system
 GET             /extended_config
-GET             /extended_config/{scope}
 GET PUT PATCH   /config
-GET PUT PATCH   /config/{scope}
 GET POST PATCH  /questions
 GET             /proposal
-GET             /status
 GET             /issues
 POST            /action
 ~~~
 
+### GET /status
+
+Reports the status of the installation. It contains the installation state (*configuring*, *installing*, *finished*) and the active progresses.
+
 ### GET /system
 
 Returns a JSON with the info of the system (storage devices, network connections, current localization, etc).
@@ -47,39 +49,51 @@ There is a distinction between *extended config* and *config*:
 
 For example, if only the *locale* was configured by the user, then the *config*  has no *keymap* property. Nevertheless, the *extended config* would have a *keymap* with the value from the default *extended config*.
 
-The scope can be indicated to retrieve only a part of the config, for example *GET /extended_config/l10n*.
+### GET PUT /config
 
-### GET PUT PATCH /config
+Reads or replaces the *config*. In case of patching, the given config is merged into the current *extended config*.
 
-Reads, replaces or modifies the explicitly set *config*. In case of patching, the given config is merged into the current *extended config*.
+### PATCH /config
 
-The scope can be indicated to manage only part of the config, for example *PUT /config/l10n*.
+Applies changes in the *config*. There is an own patch document:
 
-### POST /action
+~~~json
+{
+  "update": {
+    "l10n": {
+      "keymap": "es"
+    }
+  }
+}
+~~~
 
-Allows performing actions that cannot be done as side effect of applying a config. For example, start the installation, reload the system, etc. The *actions schema* defines the possible actions, parameters, etc.
+The given config from the *update* key is merged into current *extended config*.
 
-### GET /status
+The patch document could be extended in the future with more options, for example for resetting some parts of the config.
 
-Reports the status of the installation. It contains the installation state (*configuring*, *installing*, *finished*) and the active progresses.
+See https://datatracker.ietf.org/doc/html/rfc5789#section-2
+
+### POST /action
+
+Allows performing actions that cannot be done as side effect of applying a config. For example, start the installation, reload the system, etc. The *actions schema* defines the possible actions, parameters, etc.
 
-### Example: reload the system
+#### Example: reload the system
 
 In some cases, clients need to request a system reload. For example, if you create a RAID device using the terminal, then you need to reload the system in order to see the new device. In the future, reloading the system could be automatically done (e.g., by listening udisk D-Bus). For now, reloading has to be manually requested.
 
 ~~~
-POST /action { "reloadSystem": { scope: "storage" } }
+POST /action { "reloadSystem": "storage" }
 ~~~
 
-### Example: change the system localization
+#### Example: change the system localization
 
 Sometimes we need to directly modify the system without changing the config. For example, switching the locale of the running system (UI language).
 
 ~~~
 POST /action { "configureL10n": { language: "es_ES" } }
 ~~~
 
-### Example: start installation
+#### Example: start installation
 
 The installation can be started by calling the proper action.