One possible way of implementing this would be to convert all path-based parameters into URL-like parameters that accept Data URIs. This would automatically expose the contents of the file via the REST API as well as make them editable without having to overwrite or modify the existing files, something which can have serious security implications if done via the method of writing out the payload contents to the given file path. This approach also makes it automatically work with the configuration synchronization which would otherwise require out-of-bounds data to transfer the files. As the contents are in a standard format, they are easily convertible to a form that could be edited manually via the GUI.

This should be a fully backwards compatible extension to the MaxScale configuration. Support for paths is still retained by checking if a pathname (or possibly a file URI) is given as an argument to the parameter. The displaying of the file could be done in two different ways, either by returning both the path where the file was read from or by changing the format depending on the request options. For the version that uses a HTTP option (e.g. "export=true"), an approach similar to the password handling in the configuration synchronization (unmask the passwords for export, mask them for the REST API) could be taken.

Here's an example cache filter rule file

{

  "store": [

    {

      "attribute": "table",

      "op": "=",

      "value": "sbtest"

    }

  ]

}

Converting it into a data URI form would result in the REST API returning one the following types:

  // Current approach

  "rules": "/path/to/rules.json"

  // The data URI version, optionally sent if "export=true" is used

  "rules": "data:;base64,ewogICJzdG9yZSI6IFsKICAgIHsKICAgICAgImF0dHJpYnV0ZSI6ICJ0YWJsZSIsCiAgICAgICJvcCI6ICI9IiwKICAgICAgInZhbHVlIjogInNidGVzdCIKICAgIH0KICBdCn0="

  // Combined version with both the data and the source

  "rules": {

    "data": "data:;base64,ewogICJzdG9yZSI6IFsKICAgIHsKICAgICAgImF0dHJpYnV0ZSI6ICJ0YWJsZSIsCiAgICAgICJvcCI6ICI9IiwKICAgICAgInZhbHVlIjogInNidGVzdCIKICAgIH0KICBdCn0=",

    "source": "/path/to/rules.json"

  }

The downside of this approach is that the Base64 encoding is only 75% efficient. This can be mostly avoided by conditionally using it if the file could not be sent in plaintext URL-safe form. Another problem is the lack of a "source" for modifications done via the REST API: an inline document won't tell where it came from whereas a path to a file does. One could argue that this is not a problem but a feature of the design and that a lack of source implies that it was created via the REST API and/or GUI. This also causes problems with files that have sensitive information (e.g. TLS private keys) but this is mostly avoided by not allowing such files to be used in this manner or by using something like the key manager for fetching secrets.

A URI-based approach would also theoretically allow files to be fetched from remote servers or even S3 buckets. This might be useful for some things like public certificates or locally shared resources but in general it seems to open up more problems than it solves.