Overview

In contrast to the "Multiple Interface" and "Namespace" approach, the idea here is to use standard interfaces and standard paths that Okapi has supported for years. Each module uses a different path for its configuration.

Path Interface Support

Already exists. No changes needed in Okapi.

Stripes Support

Already exists, fetching and processing the configuration JSON works just the same as any other data JSON.

Examples

Several modules already use "Distributed Configuration via Path", see these examples that show CRUD configuration APIs:

Schema

kv_configuration.schema

One option is to re-use the mod-configuration schema: https://github.com/folio-org/mod-configuration/blob/v5.6.0/ramls/_schemas/kv_configuration.schema . Example:

{ "module": "CIRCULATION",
  "configName": "validation_rules",
  "code": "PATRON_RULE",
  "description": "for patrons",
  "default": true,
  "enabled": true,
  "value": "the rule ..." }

We could copy kv_configuration.schema to https://github.com/folio-org/raml/tree/raml1.0/schemas so that all modules can use it for their module specific configuration API.

This might help migrating a configuration from mod-configuration to some other module (the "module" property is only needed if clients like the settings front-end still generate it).
However, the help is probably very limited and not worth the effort so that a custom schema should be used.

Custom

A custom schema can be used. When migrating from mod-configuration we can remove all fields that are not needed. The "configName" and "value" properties are merged, using the example above yields

{ "validation_rules": "the rule ...",
  "description": "for patrons" }

Pros/Cons

Pros

• Doesn't require use of an additional headers or additional parameter
• No change needed in Okapi and Stripes
• Front-end can use existing standard stripes-connect and standard JSON processing methods.
• RMB provides default CRUD implementations for the storage module: PgUtil.get, PgUtil.put, PgUtil.post and PgUtil.delete that reduce the implementation to a one-liner per HTTP method (mod-orders-storage example).
• Is in line with existing path-based configuration storage APIs (see list of examples above)
• Both simple and complex configuration options use the same path based syntax
• Doesn't introduce yet another configuration interface syntax (like "Multiple Interfaces and Scope", or "Namespace")
  
• Each module has its own configuration interface.
  • This allows for detailed module-specific API description that can be added to the API endpoint documentation at https://dev.folio.org/reference/api/
  • The configuration interface version tracks changes that affect only configuration; this is not possible if all modules share the same interface.
  • Allows other modules to depend on the specific configuration interface.
  • The individual interfaces avoid the architectural design smell that a common interface creates. A common interface should only been used for the same option (for example a timeout option) or if the configuration is stored in a central configuration service module.

Cons

• Every implementation of configuration is different, meaning separate implementations and separate client code is needed. However, this code can be extracted into a method for re-use, and the method calls differ by parameter only. The same applies to the multiple interface solution and the namespace solution.
• Each module has its own configuration interface resulting in more paperwork when comparing to the existing mod-configuration solution; the multiple interface solution and the namespace solution also require interface paperwork for each module.