From a purely technical/functional perspective, service implementations can be data- and format-agnostic. That is, there's no functional reason why a service cannot accept raw binary data input and return raw binary output. Data is data, after all. However, even in cases where a service really is concerned with data that isn't readily readable by human beings, there are advantages to formatting the incoming requests and outgoing responses, to afford some degree of human readability. At a minimum, it makes the debugging of requests and responses easier.

In that respect, request and response data share a lot of the concerns that were noted about the needs of configuration files, as follows:

• Being able to pass structured and typed data around is similarly advantageous
• Allowing that data structure to be at least somewhat comprehensible to a casual reader/observer feels like a good thing, too
• The ability to represent reasonably complex data structures—lists and nested objects—also feels advantageous

Given the same types of concerns, a similar solution to address them makes sense, which means that using a serialization format, such as JSON or YAML, also makes sense. Doing so introduces a bit of additional development effort overhead; for example, converting incoming data from JSON to a native data structure, or an outbound native data structure response to JSON. That effort will generally be pretty trivial, though.

Of those two formats, JSON is arguably a better general-purpose solution. It's well established, and it's directly supported across a wider range of potential service clients, if only because it is, essentially, a native data format for web browsers. YAML is still a viable alternative, though, particularly in cases where there is no web browser client support needed.