RabbitMQ的restful管理接口

发表时间:2017-12-04 16:43:15 浏览量( 24 ) 留言数( 0 )


学习目标:


1、了解使用rabbitmqclt进行管理

学习过程:

   一般命令可以在本机使用,web界面可以配置远程使用,但是如果你像吧某些配置集成到你的项目中,那么我们可以使用Java API,也可以使用更加简单的http api,也就是我们常见的restful的接口。

大家可以参考这个web网址,里面由api的详细说明。

http://localhost:15672/api/

比如我们要打印出所有的hosts信息,我们可以这样操作

 curl -i -u guest:guest http://localhost:15672/api/vhosts

打印出exchang

curl -i -u guest:guest "http://localhost:15672/api/channels?sort=message_stats.publish_details.rate&sort_reverse=true&columns=name,message_stats.publish_details.rate,message_stats.deliver_get_details.rate"

更多的详细的api可以参考下面的表格


GETPUTDELETEPOSTPathDescription
X


/api/overviewVarious random bits of information that describe the whole system.
XX

/api/cluster-nameName identifying this RabbitMQ cluster.
X


/api/nodesA list of nodes in the RabbitMQ cluster.
X


/api/nodes/nameAn individual node in the RabbitMQ cluster. Add "?memory=true" to get memory statistics, and "?binary=true" to get a breakdown of binary memory use (may be expensive if there are many small binaries in the system).
X


/api/extensionsA list of extensions to the management plugin.
X

X/api/definitions
/api/all-configuration (deprecated)
The server definitions - exchanges, queues, bindings, users, virtual hosts, permissions and parameters. Everything apart from messages. POST to upload an existing set of definitions. Note that:
  • The definitions are merged. Anything already existing on the server but not in the uploaded definitions is untouched.

  • Conflicting definitions on immutable objects (exchanges, queues and bindings) will cause an error.

  • Conflicting definitions on mutable objects will cause the object in the server to be overwritten with the object from the definitions.

  • In the event of an error you will be left with a part-applied set of definitions.

For convenience you may upload a file from a browser to this URI (i.e. you can use multipart/form-data as well as application/json) in which case the definitions should be uploaded as a form field named "file".
X

X/api/definitions/vhost
The server definitions for a given virtual host - exchanges, queues, bindings and policies. POST to upload an existing set of definitions. Note that:
  • The definitions are merged. Anything already existing on the server but not in the uploaded definitions is untouched.

  • Conflicting definitions on immutable objects (exchanges, queues and bindings) will cause an error.

  • Conflicting definitions on mutable objects will cause the object in the server to be overwritten with the object from the definitions.

  • In the event of an error you will be left with a part-applied set of definitions.

For convenience you may upload a file from a browser to this URI (i.e. you can use multipart/form-data as well as application/json) in which case the definitions should be uploaded as a form field named "file".
X


/api/connectionsA list of all open connections.
X


/api/vhosts/vhost/connectionsA list of all open connections in a specific vhost.
X
X
/api/connections/nameAn individual connection. DELETEing it will close the connection. Optionally set the "X-Reason" header when DELETEing to provide a reason.
X


/api/connections/name/channelsList of all channels for a given connection.
X


/api/channelsA list of all open channels.
X


/api/vhosts/vhost/channelsA list of all open channels in a specific vhost.
X


/api/channels/channelDetails about an individual channel.
X


/api/consumersA list of all consumers.
X


/api/consumers/vhostA list of all consumers in a given virtual host.
X


/api/exchangesA list of all exchanges.
X


/api/exchanges/vhostA list of all exchanges in a given virtual host.
XXX
/api/exchanges/vhost/nameAn individual exchange. To PUT an exchange, you will need a body looking something like this:
{"type":"direct","auto_delete":false,"durable":true,"internal":false,"arguments":{}}
The type key is mandatory; other keys are optional.

When DELETEing an exchange you can add the query string parameter if-unused=true. This prevents the delete from succeeding if the exchange is bound to a queue or as a source to another exchange.

X


/api/exchanges/vhost/name/bindings/sourceA list of all bindings in which a given exchange is the source.
X


/api/exchanges/vhost/name/bindings/destinationA list of all bindings in which a given exchange is the destination.



X/api/exchanges/vhost/name/publishPublish a message to a given exchange. You will need a body looking something like:
{"properties":{},"routing_key":"my key","payload":"my body","payload_encoding":"string"}
All keys are mandatory. The payload_encoding key should be either "string" (in which case the payload will be taken to be the UTF-8 encoding of the payload field) or "base64" (in which case the payload field is taken to be base64 encoded).
If the message is published successfully, the response will look like:
{"routed": true}
routed will be true if the message was sent to at least one queue.

Please note that the HTTP API is not ideal for high performance publishing; the need to create a new TCP connection for each message published can limit message throughput compared to AMQP or other protocols using long-lived connections.

X


/api/queuesA list of all queues.
X


/api/queues/vhostA list of all queues in a given virtual host.
XXX
/api/queues/vhost/nameAn individual queue. To PUT a queue, you will need a body looking something like this:
{"auto_delete":false,"durable":true,"arguments":{},"node":"rabbit@smacmullen"}
All keys are optional.

When DELETEing a queue you can add the query string parameters if-empty=true and / or if-unused=true. These prevent the delete from succeeding if the queue contains messages, or has consumers, respectively.

X


/api/queues/vhost/name/bindingsA list of all bindings on a given queue.


X
/api/queues/vhost/name/contentsContents of a queue. DELETE to purge. Note you can't GET this.



X/api/queues/vhost/name/actionsActions that can be taken on a queue. POST a body like:
{"action":"sync"}
Currently the actions which are supported are sync and cancel_sync.



X/api/queues/vhost/name/getGet messages from a queue. (This is not an HTTP GET as it will alter the state of the queue.) You should post a body looking like:
{"count":5,"requeue":true,"encoding":"auto","truncate":50000}
  • count controls the maximum number of messages to get. You may get fewer messages than this if the queue cannot immediately provide them.

  • requeue determines whether the messages will be removed from the queue. If requeue is true they will be requeued - but their redelivered flag will be set.

  • encoding must be either "auto" (in which case the payload will be returned as a string if it is valid UTF-8, and base64 encoded otherwise), or "base64" (in which case the payload will always be base64 encoded).

  • If truncate is present it will truncate the message payload if it is larger than the size given (in bytes).

truncate is optional; all other keys are mandatory.

Please note that the get path in the HTTP API is intended for diagnostics etc - it does not implement reliable delivery and so should be treated as a sysadmin's tool rather than a general API for messaging.

X


/api/bindingsA list of all bindings.
X


/api/bindings/vhostA list of all bindings in a given virtual host.
X

X/api/bindings/vhost/e/exchange/q/queueA list of all bindings between an exchange and a queue. Remember, an exchange and a queue can be bound together many times! To create a new binding, POST to this URI. You will need a body looking something like this:
{"routing_key":"my_routing_key","arguments":{}}
All keys are optional. The response will contain a Location header telling you the URI of your new binding.
X
X
/api/bindings/vhost/e/exchange/q/queue/propsAn individual binding between an exchange and a queue. The props part of the URI is a "name" for the binding composed of its routing key and a hash of its arguments. props is the field named "properties_key" from a bindings listing response.
X

X/api/bindings/vhost/e/source/e/destinationA list of all bindings between two exchanges. Similar to the list of all bindings between an exchange and a queue, above.
X
X
/api/bindings/vhost/e/source/e/destination/propsAn individual binding between two exchanges. Similar to the individual binding between an exchange and a queue, above.
X


/api/vhostsA list of all vhosts.
XXX
/api/vhosts/nameAn individual virtual host. As a virtual host usually only has a name, you do not need an HTTP body when PUTing one of these. To enable / disable tracing, provide a body looking like:
{"tracing":true}
X


/api/vhosts/name/permissionsA list of all permissions for a given virtual host.
X


/api/usersA list of all users.
XXX
/api/users/nameAn individual user. To PUT a user, you will need a body looking something like this:
{"password":"secret","tags":"administrator"}
or:
{"password_hash":"2lmoth8l4H0DViLaK9Fxi6l9ds8=", "tags":"administrator"}
The tags key is mandatory. Either password or password_hash must be set. Setting password_hashto "" will ensure the user cannot use a password to log in. tags is a comma-separated list of tags for the user. Currently recognised tags are administratormonitoring and managementpassword_hash must be generated using the algorithm described here.
X


/api/users/user/permissionsA list of all permissions for a given user.
X


/api/whoamiDetails of the currently authenticated user.
X


/api/permissionsA list of all permissions for all users.
XXX
/api/permissions/vhost/userAn individual permission of a user and virtual host. To PUT a permission, you will need a body looking something like this:
{"configure":".*","write":".*","read":".*"}
All keys are mandatory.
X


/api/parametersA list of all vhost-scoped parameters.
X


/api/parameters/componentA list of all vhost-scoped parameters for a given component.
X


/api/parameters/component/vhostA list of all vhost-scoped parameters for a given component and virtual host.
XXX
/api/parameters/component/vhost/nameAn individual vhost-scoped parameter. To PUT a parameter, you will need a body looking something like this:
{"vhost": "/","component":"federation","name":"local_username","value":"guest"}
X


/api/global-parametersA list of all global parameters.
XXX
/api/global-parameters/nameAn individual global parameter. To PUT a parameter, you will need a body looking something like this:
{"name":"user_vhost_mapping","value":{"guest":"/","rabbit":"warren"}}
X


/api/policiesA list of all policies.
X


/api/policies/vhostA list of all policies in a given virtual host.
XXX
/api/policies/vhost/nameAn individual policy. To PUT a policy, you will need a body looking something like this:
{"pattern":"^amq.", "definition": {"federation-upstream-set":"all"}, "priority":0, "apply-to": "all"}
pattern and definition are mandatory, priority and apply-to are optional.
X


/api/aliveness-test/vhostDeclares a test queue, then publishes and consumes a message. Intended for use by monitoring tools. If everything is working correctly, will return HTTP status 200 with body:
{"status":"ok"}
Note: the test queue will not be deleted (to to prevent queue churn if this is repeatedly pinged).
X


/api/healthchecks/nodeRuns basic healthchecks in the current node. Checks that the rabbit application is running, channels and queues can be listed successfully, and that no alarms are in effect. If everything is working correctly, will return HTTP status 200 with body:
{"status":"ok"}
If something fails, will return HTTP status 200 with the body of
{"status":"failed","reason":"string"}
X


/api/healthchecks/node/nodeRuns basic healthchecks in the given node. Checks that the rabbit application is running, list_channels and list_queues return, and that no alarms are raised. If everything is working correctly, will return HTTP status 200 with body:
{"status":"ok"}
If something fails, will return HTTP status 200 with the body of
{"status":"failed","reason":"string"}