When JSON- and when message definition schemas for REST?

We have a interface-separate-from-data architecture that also separates the entities that is used for integration separate from the actual data (i.e. WebService entities). During all our REST integrations, we use JSON-based schemas, not XML, WSO or message definitions. Lately I’ve been wondering about the advantages of message definitions over other schemas, primarily JSON. Message definitions, for starters, seem easier as we don’t have to write any JSON, escaping human error in writing. What are the (dis)advantages of using a message definition over JSON schemas?   All I could yet find is that the primitive type on both sides of the mapping are equal. We, however, convert decimals to longs when transferring the data. That might make message definitions more difficult to use.
2 answers

One advantage and the main reason for the existence of message definitions is the ability to abstract your message definition away from the use of it. Message definitions can get used in both JSON- and XML-messages. Which is nice.

A disadvantage is that you need to either have the domain entities present or create entities for the message, usually non-persistent.


I have seen instances where the order in the messages is very important and strict, then the json will allow for accommodating this while the message definition will not.