https://bugzilla.wikimedia.org/show_bug.cgi?id=38716
--- Comment #6 from Bawolff <[email protected]> 2012-08-02 19:17:51 UTC --- >Just to be clear I appreciate you both taking the time to discuss :-) However, keep in mind that you're discussing this with me and MzMcBride. Neither of us are exactly core API contributors by any stretch of the imagination ;). But nonetheless I love giving my 2 cents worth on bugs. >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 I could certainly understand how it does provide a logical separation of code, particularly in jQuery's ajaxy functions. However that varries wildly depending on your programming environment. People could just as easily write a layer on top of jQuery to check for errors in MW api's output and send to either the error or the success handler. My most major concern with such "restful" approaches is that it would be hard to apply consistantly. If some pages are missing and not others (Even if all pages are missing, that's not even considered an error in the current code). If some of the parameters are invalid but not others (although a case could be made that a request should either be entirely valid, or not valid at all). To be consistent we should respond similarly for a partially wrong request as we do for an entirely wrong, but an error code can only apply to the entire request. We do use error codes in the normal interface for page not found, if the page does not exist. >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. Well the robots.txt fixes that issue nicely (At least in Wikimedia land). There are use cases for having the api response for non-private requests stick around in the squid cache for a bit. If search engines manage to spider a public api response, it aint exactly a big deal either. >To give a concrete example, you should remember that it is still possible for >me to cause a 500 error using the api. Only in cases of PHP fatal errors, and squid timeouts I thought? (Which would entirely be appropriate even if we didn't use status codes in general, because that is signaling that the layer below the api failed). >...and this guy [1] seems to agree. It also opens up a path to having a generic >error handler for all requests. No doubt. Even though REST-fullness isn't quite the buzzword it used to be, it still has many many fans. Personally I've always thought it was a bit over-rated, but that is just me (I don't mean that restful api's are bad per se, just that restful paragadigm is not a magic bullet, and its just as easy to design a bad api that is restful as it is to design a bad api that is not-restful. Case in point, trying to get anything useful out of the restful version of the bugzilla api). Non-trivial generic error handlers are quite difficult to write ( API returned an error (any error, with exception to maybe 504 from squids), what the client should do varries greatly depending on the situation >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. Just as trivial to use MW's internal logging infastructure. (Although for third party re-users who want that info, the status code may be easier for them). We already keep track of which methods take the most time and stuff ( http://gdash.wikimedia.org/dashboards/apimethods/ ) I doubt adding response codes would make it any more or less dificult to track response types. -- 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
