I think this is a question of approach, and you are right on "failing to see the benefits" of such restriction. Your service has a defined API; some of the entries require structured data (commands and data objects), others process streams (file upload). If I see it in this way, I see no problem.
- If you have to accept something as a stream, you don't force anyone using an improper format (now JSON), but let them send you that file in the most natural way. This is not "breaking" some rule, but the simplest way to do the job. KISS.
- If you have to process data hierarchies from the client: commands and objects, yes, it is nice to give one, and perhaps the easiest way to send you hierarchies, JSON is okay. For your clients.
But for you inside the service, it is not beneficial to actually see JSON, because that is only a stream syntax and the handler components around it (the same exists for XML and perhaps other formats as well). Your codes don't need JSON, they need data hierarchies. So my advice here is to hide the fact that now you use JSON format and handlers, from all of your higher level codes. The options:
- deserialize to actual object instances within your platform,
- convert to a hierarchy of Maps, Dictionaries or alike
- or hide the actual JSON node objects behind a simple interface with getAttribute, getChildren, etc. methods.
At least this is how I see it.