GET

We can use the HTTP GET method with the /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist resource to get a list of available messages from the specified queue on the specified queue manager.

Browses a summary list of messages from the specified queue manager and queue. The queue manager must be on the same machine as the mqweb server. The summary data is returned in the HTTP response body as a JSON formatted array. The data does not contain the payload of the messages and is received using the current user context. No messages are removed from the associated queue.

If a request is made to get a list of available messages from a queue that is GET inhibited, an empty JSON array is returned.


Resource URL

https://host:port/ibmmq/rest/v2/messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist

    qmgrName
    Specifies the name of the queue manager to connect to for messaging. The queue manager must be on the same machine as the mqweb server.
    The queue manager name is case-sensitive.
    If the queue manager name includes a forward slash, a period, or a percent sign, these characters must be URL encoded:

    • A forward slash (/) must be encoded as %2F.
    • A percent sign (%) must be encoded as %25.

    queueName
    Specifies the name of the queue from which to browse the messages.
    The queue must be defined as being local or an alias that points to a local queue.
    The queue name is case sensitive.
    If the queue name includes a forward slash or a percent sign, these characters must be URL encoded:

    • A forward slash, /, must be encoded as %2F.
    • A percent sign, %, must be encoded as %25.

We can use HTTP instead of HTTPS if you enable HTTP connections. For more information about enabling HTTP, see Configure HTTP and HTTPS ports.


Optional query parameters

    correlationId=hexValue
    Specifies that the HTTP method returns the next message with the corresponding correlation ID.

      hexValue
      The query parameter must be specified as a 48 character hexadecimal encoded string, representing 24 bytes.
      For example:
      ../messagelist?correlationId=414d5120514d4144455620202020202067d8bf5923582e02

    messageId=hexValue
    Specifies that the HTTP method returns the next message with the corresponding message ID.

      hexValue
      The query parameter must be specified as a 48 character hexadecimal encoded string, representing 24 bytes.
      For example:
      ../messagelist?messageId=414d5120514d4144455620202020202067d8ce5923582f07

    limit=integerValue
    Specifies that the HTTP method response body is limited to integerValue JSON elements.

      integerValue
      The query parameter must be specified as an integer value that represents the maximum number of elements that are contained in the JSON response body.
      The default value is 10, and the maximum value is 2147483647.
      For example:
      ../messagelist?limit=250


Request headers

The following headers must be sent with the request:

    Authorization
    This header must be sent if we are using basic authentication. For more information, see Use HTTP basic authentication with the REST API.

    ibm-mq-rest-csrf-token
    This header must be set, but the value can be anything, including being blank.

The following headers can optionally be sent with the request:

    Accept-Charset
    This header can be used to indicate what character set is acceptable for the response. If specified, this header must be set as UTF-8.

    Accept-Language
    This header specifies the required language for any exceptions or error messages returned in the response message body.


Request body format

None.


Security requirements

The caller must be authenticated to the mqweb server. The MQWebAdmin and MQWebAdminRO roles are not applicable for the messaging REST API. For more information about security for the REST API, see IBM MQ Console and REST API security.

Once authenticated to the mqweb server the user is capable of using both the messaging REST API and the administrative REST API.

The security principal of the caller must be granted the ability to browse messages from the specified queue:

  • The queue that is specified by the {queueName} portion of the resource URL, must be BROWSE enabled.
  • For the queue that is specified by the {queueName} portion of the resource URL, +GET, +INQ, and +BROWSE authority must be granted to the security principal of the caller.
  • For the queue that is specified by the {queueName} portion of the resource URL, UPDATE, access must be granted to the security principal of the caller.

On UNIX, Linux, and Windows, we can grant authority to security principals to use IBM MQ resources by using the setmqaut command. For more information, see setmqaut (grant or revoke authority).

On z/OS, see Set up security on z/OS.


Response status codes

    200
    Message list received successfully.

    400
    Invalid data provided.
    For example, an invalid query parameter value was specified.

    401
    Not authenticated.
    The caller must be authenticated to the mqweb server and must be a member of one or more of the MQWebAdmin, MQWebAdminRO, or MQWebUser roles. The ibm-mq-rest-csrf-token header must also be specified. For more information, see Security requirements.

    403
    Not authorized.
    The caller is authenticated to the mqweb server and is associated with a valid principal. However, the principal does not have access to all, or a subset of the required IBM MQ resources, or is not in the MQWebUser role. For more information about the access that is required, see Security requirements.

    404
    Queue does not exist.

    500
    Server issue or error code from IBM MQ.

    501
    The HTTP response could not be constructed.
    For example, the received message has an incorrect type, or has the correct type but the body could not be processed.

    502
    The current security principal cannot receive the message as the messaging provider does not support the required function. For example, if the mqweb server class path is invalid.

    503
    Queue manager not running.


Response headers

    Content-Language
    Specifies the language identifier of the response message in the event of any errors or exceptions. Used in conjunction with Accept-Language request header to indicate the required language for any error or exception conditions. The mqweb server default is used if the requested language is unsupported.

    Content-Length
    Specifies the length of the HTTP response body, even when there is no content. The value contains the length of the message data, in bytes.

    Content-Type
    Specifies the type of response body. Upon success the value is text/plain;charset=utf-8. In the event of any errors or exceptions, the value is application/json;charset=utf-8.


Response body format

Upon success, the response body is a UTF-8 encoded response. The response contains an outer JSON object that contains a single JSON array called messages. Each element in the array is a JSON object that contains information about a message on the queue. Each element contains the follwoing attributes:

    correlationId
    Specifies the correlation ID of the message. The value is returned if the message contains a valid correlation ID. It is represented as a 48-character hexadecimal encoded string, representing 24 bytes.

    messageId
    Specifies the message ID that is allocated by IBM MQ to this message. It is represented as a 48-character hexadecimal encoded string, representing 24 bytes.

    format
    Specifies the MQMD format field. Under normal circumstances text messages will contain the IBM MQ MQSTR value.

If a request is made to get a list of messages on a queue that is GET inhibited, an empty JSON array is returned.

If an error occurs, the response body contains a JSON formatted error message. For more information, see REST API error handling.


Examples

The following examples use the v2 resource URL. If you are using a version of IBM MQ earlier than Version 9.1.5 we must use the v1 resource URL instead. That is, in the resource URL, substitute v1 where the example URL uses v2.

The following example logs in a user called mquser with the password mquser. In cURL, the log in request might look like the following Windows example. The LTPA token is stored in the cookiejar.txt file by using the -c flag: 
curl -k "https://localhost:9443/ibmmq/rest/v2/login" -X POST 
-H "Content-Type: application/json" --data "{\"username\":\"mquser\",\"password\":\"mquser\"}" 
-c c:\cookiejar.txt

After the user is logged in, the LTPA token and ibm-mq-rest-csrf-token HTTP header are used to authenticate further requests. The ibm-mq-rest-csrf-token token_value can be any value, including blank.

  • The following Windows cURL example lists the next ten available messages from queue Q1 on queue manager QM1, using default options: 
    curl -k "https://localhost:9443/ibmmq/rest/v2/messaging/qmgr/QM1/queue/Q1/messagelist" 
-X GET -b c:\cookiejar.txt -H "ibm-mq-rest-csrf-token: token-value" 
-H "Accept: text/plain"
  • The following Windows cURL example lists the next two hundred available messages from queue Q1 on queue manager QM1, using default options: 
    curl -k "https://localhost:9443/ibmmq/rest/v2/messaging/qmgr/QM1/queue/Q1/messagelist?limit=200" 
-X GET -b c:\cookiejar.txt -H "ibm-mq-rest-csrf-token: token-value" 
-H "Accept: text/plain"
  • The following Windows cURL example lists only those messages with the corresponding correlation ID, 0000000000000000000000000000000000000000abcdabcd, from queue Q1 on queue manager QM1: 
    curl -k "https://localhost:9443/ibmmq/rest/v2/messaging/qmgr/QM1/queue/Q1/messagelist?correlationId=0000000000000000000000000000000000000000abcdabcd" 
-X GET -b c:\cookiejar.txt -H "ibm-mq-rest-csrf-token: token-value" 
-H "Accept: text/plain"

Parent topic: /messaging/qmgr/{qmgrName}/queue/{queueName}/messagelist