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 /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.
