The Management API in WildFly is accessible through multiple channels, one of them being HTTP and JSON.
Even if you haven't used a curl command line you might already have used this channel since it is how the web console interact with the Management API.
WildFly 9 is distributed secured by default, the default security mechanism is username / password based making use of HTTP Digest for the authentication process.
Thus you need to create a user with the add-user.sh script.
Since we must be authenticated , the client will have to support HTTP Digest authentication.
For example this can be activated in curl using the --digest option.
The WildFly HTTP Management API adheres to the REST principles so the GET operations must be idempotent.
This means that using a request with method GET can be used to read the model but you won't be able to change it.
You must use POST to change the model or read it. A POST request may contain the operation either in DMR or in JSON format as its body.
You have to define the Content-Type=application/json header in the request to specify that you are using some JSON.
If you want to submit DMR in the request body then the Content-Type or the Accept header should be "application/dmr-encoded".
While you can do everything with POST, some operations can be called through a 'classical' GET request.
These are the supported operations for a GET :
- attribute : for a read-attribute operation
- resource : for a read-resource operation
- resource-description : for a read-resource-description operation
- snapshots : for the list-snapshots operation
- operation-description : for a read-operation-description operation
- operation-names : for ad read-operation-names operation
The URL format is the following one : http://server:9990/management/<path_to_resource>?operation=<operation_name>&operation_parameter=<value>...
path_to_resource is the path to the wanted resource replacing all '=' with '/' : thus for example subsystem=undertow/server=default-server becomes subsystem/undertow/server/default-server.
So to read the server-state :
- This is simple operation that is equivalent of running :read-attribute(name=server-state) with CLI in root directory
- Using GET
- Using POST
- Here's an example of an operation on a resource with a nested address and passed parameters. This is same as if you would run /host=master/server=server-01:read-attribute(name=server-state)
- Following example will get us information from http connection in undertow subsystem including run-time attributes
This is the same as running /subsystem=undertow/server=default-server:read-resource(include-runtime=true,recursive=true) in CLI
- Using GET
- Using POST
- You may also used some encoded DMR but the result won't be human readable
- You can deploy applications on the server
- First upload the file which will create a managed content. You will have to use http://localhost:9990/management/*add-content*
- Now let's deploy the application