[discussion] Revise configuration endpoints according to the RFC

[0x009922]

Description

According to the Configuration Overhaul RFC (#2585), the current configuration endpoints should be revised.

Current Design

Iroha's API currently provides two endpoints related to configuration:

• POST /configuration: Allows runtime updating of the configuration. As of now, it only supports modifying the log level using a request body structured as {"LogLevel":"<level>"}.
• GET /configuration: Serves a dual purpose; it can either return the entire configuration in a JSON format or provide documentation for a specific field.

From the Configuration Endpoints section of the RFC

Detailed Proposal

For the reasoning please refer to the Proposal 9 of the RFC.

• Remove documentation fetching via API
• Use the same naming conventions as used in the config file (or ENV)
• Use GET/POST /configuration for fetching and updating the subset of configuration parameters. The subset and format should be the same between the two endpoints for the sake of uniformity.
• While updating the configuration accepts partial structure (i.e. user might specify only those fields they need to update), retrieval always returns the whole subset. Note: this is not relevant now because we only have a single dynamic parameter.

The only dynamic parameter as of now is logger.level (according to the updated naming of parameters). Therefore, the following JSON request might be used to update the value with POST /configuration:

{
  "logger": {
    "level": "DEBUG"
  }
}

The same will be returned by GET /configuration.

Caveats

In that place of the docs it is recommended to get peers' configuration in the network through the configuration endpoint. It suggests me that probably retrieval of the configuration might include more fields than only dynamic ones.

Also

There is an issue:

• [suggestion] Uniform configuration endpoint #3107

, which suggests using sub-routing in a way it is used in GET /status endpoint. In general, I don't see a conflict here and it might be adopted for the new configuration endpoints:

Samples

Getting whole configuration:

GET /configuration

{
  "logger": {
    "level": "DEBUG"
  }
}

Getting a logger part:

GET /configuration/logger

{
  "level": "DEBUG"
}

Getting logger.level precisely:

GET /configuration/logger/level

"DEBUG"

Updating logger parameters:

POST /configuration/logger

{
  "level": "DEBUG"
}

[Erigara]

In that place of the docs it is recommended to get peers' configuration in the network through the configuration endpoint. It suggests me that probably retrieval of the configuration might include more fields than only dynamic ones.

Consensus critical parameters are now configured on-chain, so i'm not sure this section is still relevant.

[Erigara]

Other than that i have no objections or additional comments.

[Mingela]

Fine to me as well

[Arjentix]

Looks fine to me too

[DCNick3]

Use GET/POST /configuration for fetching and updating the subset of configuration parameters

If it's a subset, I think a PATCH request method makes more sense here.

Otherwise, I think it's a good design!