Consider adopting RFC7807 (JSON Problem Object) for errors

[Clockwork-Muse]

Although functions should do most of their own error handling and return serialization, there are a few areas where Azure handles or returns errors before client functions are even woken up or called. (Current most vexing case: JSON deserialization, especially if it doesn't pass validation)

For those times, consider adopting/returning RFC7807 (JSON Problem Object), or one of the other potentially relevant standards (such as JSON RPC).
This behavior may have to be opt-in (or opt-in to force), although automatic detection is likely possible:

• The current standard for JSON RPC requires a top-level "jsonrpc": "2.0" field.
• XML RPC has a <methodCall> root element.
• XML vs JSON is reasonably easy to detect.

Doing this would make client callers able to act as if the messages Azure generates come from the hosted function itself. This is likely to be particularly important if the function host is going to insist on being strongly typed and do deserialization on my behalf; I'd really like a 400 telling me, specifically, that my JSON object is invalid, or is missing this or that required field, or whatever.