Add `format` as top-level parameter?

[bmschmidt]

Currently, a top level API call parameter is method, but it's doing two different types of things.

The first is specifying what kind of call the user is making; returning search results, getting a list of available fields for a given bookworm, or returning data for a plot.

The second is specifying the format for the returned data to be in: TSV, JSON, a pickled pandas frame, etc. (Not really etc., but it could be.

Currently, those second formats are all direct method calls that only work for returning data. But logically, these are different types of operations; you might want a csv of search results or available fields, but currently we only return JSON.

Currently, this is illogical but not a huge problem. The one issue I see is that if users want to download a list of search results, currently we can only return it to them as JSON; but ordinary people don't know what to do with a JSON array of HTML strings, but we might be able to usefully reformat the results as a CSV file of just the search text.

The place this will really break down, for example, is if we were to allow JSONP calls for any webserver to make cross-domain calls. JSONP should be a format just like JSON; but for a bookworm to work, you'd need to be able to return all three types of methods, not just the data, as JSONP.

I imagine this would default to JSON, so most current queries would keep running normally as-is; we might need a little back-compatibility glue to restructure queries of the form {"method":"return_tsv",...} to {"method":"data","format":"tsv",...}.

And of course, there's the question of what the standard method would be called. I guess I'm thinking "data."

[organisciak]

This is a good idea.

The kink I've run into is that I tried to force return_json for a script that I use, but it conflicted with method:'returnPossibleFields'.