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.
