https://bugzilla.wikimedia.org/show_bug.cgi?id=38716
--- Comment #5 from Jon <[email protected]> 2012-08-02 18:39:43 UTC --- Just to be clear I appreciate you both taking the time to discuss :-) For a bit of background I have spent most of my time working with RESTful apis - so I have been a bit spoilt. I'd love this kind of API for mediawiki but this is likely to be a big task. Although using response codes would also be a big task it seems something that we can introduce slowly. To be clear as bawolf picked up - I am not adverse to having the richer data about the error sent in the response code. e.g. a 400 would be accompanied with the JSON string { error: { ... however some developers can ignore it in cases where it just doesn't matter. My main point of frustration is that to a newcomer to your code, it seems very strange that you'd package an error handler into your success callback To give a concrete example, you should remember that it is still possible for me to cause a 500 error using the api. This means I end up with a complicated error handler which first checks status code and then on a 200 inspects the result. My success handler must also do a conditional if statement and is not as clean as it could be. With status codes my success handler gains a much cleaner workflow - See http://pastebin.com/Nvg82B8w - it just feels cleaner... and this guy [1] seems to agree. It also opens up a path to having a generic error handler for all requests. It's also worth noting that any api response is cacheable and could technically be picked up by search engines. Using response codes such as 404 for errors would fix this. Another benefit of using response codes is analytics. It would be trivial to see how often the api is hit with invalid requests and to identify rooms for improvement as status codes are cached in log files. [1] http://www.bennadel.com/blog/1860-Using-Appropriate-Status-Codes-With-Each-API-Response.htm -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
