Q:

RabbitMQ Request/Response payload structure

I'm designing a system that will use RabbitMQ for request/response between applications.
I'm used to working with REST APIs and coming from that background I've been thinking how to structure messages when doing request/response.
I need to structure it to handle several scenarios:

Getting / querying data from a remote server
Creating data on a remote server
Handling client side errors 

I'm planning to have the payload JSON formatted. And I was thinking about  using some kind of response codes similar to HTTP(maybe using the same codes?) and set the response code as a property/header on the message.
For getting/querying my idea was to have a query property in the payload object.
But that got me thinking that I might be thinking this too much like REST APIs and there could be some better, more-established way of doing this.
I've been reading the book "RabbitMQ in Action" while setting this up but I see no mention of this there. My google-fu has also failed me and not provided any results.
Anyone with experience willing to share how they structure their messages?

A:

If you are using RabbitMQ in a request/response scenario among applications that are already familiar or implemented to handle REST calls, there is no need for you to deviate from it in RabbitMQ for the message format.
From your question, what I gather is that RabbitMQ acts as an intermediate server in between your application. You mention three scenarios. If you take retrieving data and writing data, here RabbitMQ acts only as a router between the application which requests to retrieve or write data and the application that retrieves and writes data. If it so, there is already a standard message format that serving application (the server with data) may support. Assume it does not already have a standard defined. In this case, you can think in terms of what the application expects in the request payload. Forget the intermediate RabbitMQ server during this stage. Thinking about the RabbitMQ messages might deviate you from using the best practices. 
As for the client side errors, you cannot directly set the HTTP status codes as headers as it will interfere with the RabbitMQ errors in the consumer. I believe, in this case you will have to use a customization by passing a custom header and converting it to a HTTP Status Code later on. 

