https://bugzilla.wikimedia.org/show_bug.cgi?id=38716
MZMcBride <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from MZMcBride <[email protected]> 2012-08-01 01:36:36 UTC --- (In reply to comment #2) > Well.. since this uri currently returns content in a new api it would still > return a 200 OK as it returns content. > > The warnings are not error messages and just there for further information. A > developer doesn't need to worry about them. I don't see any issue with > altering > the content of the response, I just believe that it should be possible to > handle errors better in javascript. Bawolff's point was that there are a lot of edge cases. Developers and programmers like reliability and having their expectations met. If the status codes perfectly aligned with every API request, it'd be great to use them. But given that they'll have to be imperfectly aligned, I'm not sure if this will create a better or worse situation. If there's ambiguity in what the response code will be when you make a request such as pulling links to a page that's been deleted (would that be a 200 because there are results [and what if there are no results?] or a 404 because the page has been deleted?), you end up making the situation worse for developers, I think. I'm not sure how you'd avoid ambiguity except by limiting different response codes to very limited situations. Where are you seeing this problem specifically? It'd be helpful if you could elaborate on the problems you're encountering in JavaScript. Feel free to paste snippets of code if you'd like, comparing what you do vs. what you could do if this bug were resolved. This bug is lumping all API requests with all status codes, but it may make sense to only change the response header in specific situations (such as when logging in via the API). Or maybe that would be worse. > This is not about being anal, it's about being more helpful and giving richer > information in our responses. This is kind of silly. The response "you supplied an invalid password' or whatever is vastly more helpful and richer in information than an error code. I think your argument is that better programmatic responses would be nice to have. This may be, but I think you should make a stronger case. (In reply to comment #0) > I understand there are backward compatibility issues but it should be possible > to access an alternative flavour of the API (E.g. accessed via > http://en.wikipedia.org/w/apiv2.php) Versioning the API is covered by another bug, I think. This bug needs an accompanying RFC and a lot more thought if you're really considering version 2 of the MediaWiki API. That isn't a small project. :-) -- 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
