Transactional considerations

HTTP is not a transactional protocol, therefore no transactional coordination of messaging operations performed by the MQ Service Provider is possible.

This has the following implications:

If an HTTP POST is made to a one-way service and the connection fails before an HTTP response is received by the client, the client can not immediately tell if the message was sent to the configured queue or topic, or not.
If an HTTP DELETE is made to a one-way service and the connection fails before an HTTP response is received by the client, then a message might have been destructively got from the queue and lost, as there is no way of rolling the destructive get back.
If an HTTP POST is made to a two-way service and the connection fails before an HTTP response is received by the client, the client can not tell where the failure occurred. The request message might have been sent to the request queue, or the response message might have been got from the response queue and lost.
There is no way to coordinate the outcome of multiple HTTP verbs, to either a one-way or a two-way service.