All resoures now use the `state` member to describe their internal
state. This includes servers, services and monitors. This means that the
`status` keyword can be reserved for something else and it can be removed
until it is needed again.
Changed the module maturity field to `maturity` to better describe its
purpose.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.
The test created a DCB of an unexpected type in an unexpected state with
an invalid file descriptor. This caused the test to fail due to a debug
assertion where the the validity of the file descriptor was asserted in
relation to the internal state of the DCB.
The module commands can now produce JSON formatted output which is passed
to the caller. The output should conform to the JSON API as closely as
possible.
Currently, the REST API wraps all JSON produced by module commands inside
a meta-object of the following type:
{
"meta": <output of module command>
}
This allows the output to be JSON API conformant without modifying the
modules and allows incremental updates to code.
The PATCH method should now be used instead the PUT method to update
resources. As PUT request bodies should represent complete resources, the
use of PUT to update resources is no longer supported.
Altered tests to use PATCH instead of PUT for updating resources.
The module command self links now point to an endpoint that executes the
module command. Depending on the type of the module command, either a GET
or a POST request must be made.
The /maxscale/ resource now supports PUT requests which modify core
parameters. As not all parameters can be changed at runtime, only
modifications to parameters that support runtime configuration are
allowed.
The /users/ resource shows all user accounts that can be used with
MaxScale. This resource is further split into two resource collections,
/users/inet and /users/unix, which contain the network users and Linux
accounts respectively.
The requests that send a body should define at least a `data` member.
Added a simple test that checks that bad requests are rejected. This test
should be expanded to check that the returned error body contains the
correct members.
The top level resource self links pointed to the collection instead of the
resource itself. The individual resoures now also have a links field that
contains the self link to the resource. This should make navigation of the
API easier as all objects have valid links in them.
The REST API now supports the If-Modified-Since, If-Unmodified-Since,
If-Match and If-None-Match headers and returns the correct response if the
conditional fails.
Added tests for the date parsing and expanded the HTTP header tests in the
REST API test suite.
The resource system now tracks both the time when a resource was last
modified and the revision number of the resource. This allows working
Last-Modified and ETag headers to be generated by the REST API.
The If-Modified-Since and If-None-Match request headers are not yet
processed and using them will always return the resource instead of a 304
Not Modified response.
Returning 204 No Content removes the cost of always sending back the
modified resource. If the modified resource is required, a GET request
should be made to retrieve it.
Updated tests to account for this change.
The listeners under the /services/:service/listeners collection are now
fully JSON API compliant resources.
The listeners could also be exposed as a /listeners collection to easily
group all listener type resources in one place. This approach does has
some semantical and practical problems, namely the fact that each listener
has a many-to-one relationship with its service and listeners by
themselves can't exist alone.
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 creation and modification of moitor now supports the JSON API
conforming format generated by the GET endpoints.
Also added tests for creating and altering monitors via the REST API.
The tests now automatically start MaxScale before each test block and stop
it and perform cleanup after the test. This is done by simply calling the
`before.sh` and `after.sh` scripts before each test block.
The `test_rest_api` make target creates a discardable installation of
MaxScale which is used to launch a local instance of MaxScale. This local
instance is then used to test the REST API.
This is definitely not an efficient way to test the MaxScale but it allows
local testing without virtual machines or containers.
Using the JSON Pointer syntax specified in RFC 6901
(https://tools.ietf.org/html/rfc6901) allows for a convenient way to
access values deep in a JSON object.
The atomic compare-and-swap can be used to implement lock-free
structures. The planned use for this is to remove some of the locking done
in the services when listeners are being manipulated.
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.
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.
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.
