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.
Some time later you might be unable to force a client to use JSON, because their systems communicate through XMLs, can only use plain forms without JavaScript, or their data is actually in a database. Then you will love the concept of having JSON invisible to the rest of your code by any of the above means: you then just write the next wrapper for that XML (or HTTP request parameter package, whatever), and you are done: the same API and code can be reached through another "data language".
At least this is how I see it.