The JSON API specification suggests that the API returns the 403 Forbidden
error when the user does an invalid request. The 400 Bad Request isn't the
ideal error for cases where the syntax is correct but the action being
performed is wrong.
The modules, their types and default values are exposed via the
/maxscale/modules resource. Currently, only a list of resources can be
exposed as the externally exposed module object (MXS_MODULE) does not have
the name and type information in it.
Destroyed servers were still shown as a part of the servers resource
collection.
If a parameter defined in persisted configurations was replaced, the value
would be appended to itself after it was replaced.
Return correct error codes for internal errors.
The server check was checking for old parameter locations.
Service parameters can now be altered with a PUT request to the REST
API. This allows general level parameters to be altered.
Module specific parameters need to be altered with a different mechanism,
namely the module command system. This requires that a generic way to call
a function needs to be devised.
The PATCH method isn't supported in older versions of microhttpd. As this
functionality wasn't used, it can be removed until it is needed. The PUT
method already allows updates by defining complete resources so PATCH is
only an improvement, not a requirement.
Monitor resources can now be altered with a PUT request. The method allows
alterations on all parameters that the maxadmin `alter monitor` command
allows.
The /sessions/ resource was not implemented due to changes in the core
polling mechanics. With the new worker thread messaging system, sessions
can be listed in a safe manner.
All resources now support HEAD and OPTIONS methods.
The HEAD response is generated by truncating a GET request on the same
resource. This does not work with other methods as they could require a
message body.
The server can now be modified with a PUT request of a modified server
resource. The server resource was reorganized to have the parameters as a
separate entity from the other more general entities of the resource.
The PUT/POST functions return a more appropriate error message when no
request body is provided.
Moved some of the constant names used in server.cc into the config.h
header.
Cleaned up various parts of the resource, request and response class
headers.
Moved `using` declarations into .cc files.
Made the Resource class non-copyable as it isn't really meant to be
copied.
The resources are now declared by simply typing the path that they match
and providing a callback for that path. This makes it easier to add new
resources without having to create a new class for each added resource
endpoint. It also removes some of the pathname processing that was done
inside the child class handler functions.
The HTTP side of the REST API is better handled with an actual
library. The libmicrohttpd library provides a convenient way of handling
the HTTP traffic between the clients and MaxScale.
Monitors can now be printed in JSON format. The REST API resource
`/monitors` accepts GET requests and returns a JSON representation of the
monitors as a response.
Both the filters and services can be queried via the REST API now that
these resources can be expressed in JSON format.
As with the other resources, these directly call the functions that
generate the data. This will be done via the inter-thread messaging system
once it's in place.
The REST API now prints individual sessions and servers. It also lists all
servers if no specific server is given.
The functions directly call the printing functions when they should be
using the inter-thread messaging system. When the messaging system is
ready, these functions should be updated.
The resources now properly process parts of the uri. This allows, for
example, certain sessions to be inspected. The current functionality is
only intended for testing and provides no useful functionality.
The actions taken by the resource manager are not done via the
inter-thread messaging system. When the implementation of the messages and
the JSON representation of the resources is done, the REST API resource
can actually be used.
The Resource class is intended to be an abstraction of a resource
tree. Each node in the tree can perform actions. The tree is traversed
depth first so that deeper command paths resolve to the correct nodes.
Currently all the base resources defined in the REST API documents are
implemented in a way that they return a 200 OK response to all
requests. When the internal data can be represented as JSON, the resources
can be hooked up to functions that generate JSON.
