On 08/11/12 16:17, Chad wrote: > Assuming we did it like last time (when query.php was replaced with api.php), > we would allow the two APIs to co-exist for a period of time, but with > a declared > end of life for the old interface. > > Although considering that the number of people using api.php is many factors > more than were ever using query.php--the sunset period should be much much > longer this time. > > -Chad
I don't think it would be wise to remove the current api. Yes, it may be cool to use a PUT verb for storing wikitext in a page (aka. doing an edit). But we don't want "coolness += 1; utility -= 100;" I'm not opposed to a new branch playing with that concept, but clearly separated, please. Besides, I don't think that new developers look for "Does it have a REST interface?" when deciding if making an application. Things like "Is it well documented?" are much more important, and IMHO we are doing a good job there. Not to mention the fact of having existing libraries, of which we have a good number. If all the other wikis were using a Grand Unified Wiki Api and MediaWiki was at odds using its own one, or there were existing clients which would benefit from that change, it could be considered, but that's not available. Trashing existing documentation, people knowledge and libraries in exchange of a cool concept is a big no-no. Long live the existing api! _______________________________________________ Mediawiki-api mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
