I'm designing an API for my web app, and our content is fairly complex. For example, you can have a wiki page with multiple sub objects like tags, multiple separate content areas, and more.
I don't want to deal with a complicated, kludgy way of naming params like tag_N or tag[].
It also occurred to me that our objects can be expressed perfectly as JSON. In fact, that's our response format. If you do a GET, you receive the object in JSON format.
Is it reasonable to require that POST and PUT body of the object also be specified in JSON? For example, something like this:
{
'name' : 'My Page',
'body' : 'Some page body',
'tags' : ['tag1', 'tag2', 'tag3']
}
as opposed to
name=My%20Page&body=Some%20page%20body&tag[]=tag1&tag[]=tag2&tag[]=tag3
This is a pretty simplified example. In many cases we have complicated objects with arrays of sub-objects, who themselves also contain sub-objects. It's fairly simple to describe with JSON, but gets very difficult with query string style params.
So, the main question is: If we require the POST body to be a JSON string, is that unreasonable? Is it too far outside the norm of HTTP APIs? Would you, as the author of an API consumer, be put off by an API with a requirement like this?