Thread:Talk:Requests for comment/API Future/Reduce the amount of query parameters/reply

This one is a bit complex, will try to break it down.
 * API inconsistencies - agree, that's why I started this process, please propose individual cleanups (listed at API Cleanup (scroll up a bit, collapsable sections confuse browsers).
 * Documentation - totally agree, must be cleaner and easier to use, plus we should have a cookbook with all the common recipes. Also, I think I will make it so that the api.php page shows just the list of actions & sub-actions, and one could click on them to get a full page info about each.
 * Starting from scratch - possibly, but I think we should get the versioning and minor cleanup/reorg done first, since, as you can see, I already have a fairly good basic idea of where to take api2. The REST-style is a much more fundamental change, that would require a lot of discussion and a separate proposal, which might take considerable time, and would cause a lot more polemics. I suspect we won't be able to get it in until either api3 or a separate action=restquery module.
 * Defaults - strongly disagree. Just like SQL teaches us, SELECT * is great for development, but horrible for production. Once you know exactly what you want for the job, you should specify exactly those properties. This lowers bandwidth and frequently allows the server to do significantly less work. Moreover, I would propose we make 'props' parameters *required* unless an "fm" format is used - this way queries will return a warning with format=xmlfm or jsonfm, but will give an error when format=xml or json is given.