The actual list of headers is not known when the request is first
generated. This prevents the headers from being generated in admin.cc
which handles things on a lower level.
The moving of the header generation is done with the OPTIONS method in
mind. This header needs to be generated inside the RootResource class
which manages the navigation of the resources.
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 data was not processed correctly and instead an error was sent to the
client as soon as the request arrived.
Created a class that somewhat abstracts the internals of the client
request processing.
The relationships from servers to services and monitors and filters to
services were not implemented. Now each server lists the services and
monitors that use it and each filter lists the services that use the
filter.
This enables the creation of a server and linking of that server to
services and monitors in one atomic operation.
The JSON API (http://jsonapi.org/) specifies a way to express relations in
a somewhat generic way. By moving towards a more generic schema for the
resources, it will be easier to handle the modification of the relations
between these resources.
When a resource has a relation to another resource, it should be expressed
as a working link to the resource. By passing the hostname of the server
to the functions, we are able to generate working relation links.
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 standard response headers are now generated at a higher level. This
reduces the scope of the HttpResponse class making it a leaner wrapper
around a few simple variables, namely the JSON body of the response.
The HttpRequest now exposes the Host header that the client sent. This
allows resource relations to be real links that work without modification.
If a resource can be accessed from more than one place, it should be a
link. The previous change that duplicated the content for nested resources
wasn't a very clean solution. With links, the content is easier to browse
using a normal browser.
The admin interface now supports Basic Access authentication. This is not
a secure method of authentication and it should not be used without
unencrypted connections.
Made the admin interface port, authentication, username and password
configurable.
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.
All routers except the binlogrouter now fully implement the JSON
diagnostic entry point. The binlogrouter needs to be handled in a separate
commit as it produces a large amount of diagnostic output.
The modules that implement a diagnostics entry point now return a JSON
type object. This removes the need to format data inside the modules.
The module implementations of these are not yet complete which means that
MaxScale will fail to compile.
As a service is a collection of other resources, it makes sense to expand
those resources that were previously expressed as relative paths. This way
the API can be readily consumed without altering the pathnames to
links. The downside to this is the increased bandwidth consumption and
possible excess data.
All whitespace in object names is now converted to a compacted format with
whitespace replaced with hyphens. If a conversion takes place, a warning
is logged.
Converted some of the tests into C++ as they directly include .cc files.
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.
The functions don't modify the filters when the JSON is generated. This
means that the parameters can be const.
Minor formatting fixes to service sources.
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 admin thread now uses blocking IO. This is not optimal but it
simplifies the code by some amount.
Fixed option processing removing one extra character from key name.
Use correct member variable when checking for the option map end.
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 handler system is now usable but it doesn't perform anything
useful. Although, this will allows it to be tested for correctness.
Minor fixes to HttpResponse output and renaming of functions.
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.
When a client requests a resource, the HttpRequest class now splits the
requested resource into parts. This should help with the resource
validation and navigation.
Added test that checks that the resources are correctly split into the
correct number of arguments and that the argument contents are correct.
The options of a request are now parsed and exposed by the HttpRequest
class.
Added tests for the request options.
Also added missing error handling of invalid requests.
The class now generates default headers. The ETag and Last-Modified tags
do not represent any actual modification time or resource hash.
The basic functionality of the HTTP responses is tested by the core test
suite. More advanced testing of the whole REST API is still required.
Removed the static `create` functions as only the JSON parsing version
could generated errors and even then the errors were unlikely. By
replacing the static creator function with a normal constructor, the
HttpResponse class can now also be created on the stack making its use
easier.
The HTTP response class simplifies the response creation. The next step is
to add generation of all the default headers that are needed by the REST
API.
The HTTP request body is expected to be a valid JSON object. All other
requests are considered malformed requests and result in a HTTP 400 error.
Added the Jansson license to the LICENSE-THIRDPARTY.TXT file. Imported
some of the tests from the Jansson test suite to the HttpParser test.
The HttpParser class was renamed to HttpRequest as it parses and processes
only HTTP requests. A second class that creates a HTTP response needs to
be created to handle the response generation.
Moved some of the HTTP constants and helper functions to a separate
http.hh header.
The admin requests are now processed in blocking mode. The timing out of
connecttions is handled by a specific timeout thread that checks the state
of each admin request.
The simplification will help with the JSON parsing with PUT/POST
commands. If non-blocking IO is used, the network reading code and JSON
parsing needs a lot more work to handle partial reads.
If the administrative interface requires higher performance and
concurrency, a multi-threaded solution could be created.
The HTTP parser parses HTTP/1.1 messages into easily manageable data
structures. This should make it easier to map the HTTP requests into
actual commands in MaxScale.
When MaxScale is started, a separate thread for the administrative
interface is started. This allows the worker threads to handle client
requests while the administrative thread handles the lower priority
administrative requests.
The administrative interface responds to all request with a 200 OK HTTP
response. This allows the administrative interface itself to be tested.
The old polling message system is obsolete now that the worker messages
are implemented. The old system was only used to clean up the persistent
connection pool of a server.
It is now possible to define whether tasks are executed immediately or put
on the event queue of the worker thread. If task execution is in automatic
mode and the current executing thread is a worker thread, the
Task->execute method is called immediately.
This allows tasks to be posted from within worker threads. This is
intended to be used when purging of stale persistent connections and
printing diagnostic output via MaxAdmin. All of these actions are done
from within a worker thread.
