https://bugzilla.wikimedia.org/show_bug.cgi?id=38716
--- Comment #4 from Bawolff <[email protected]> 2012-08-02 12:12:27 UTC --- >This is not about being anal, it's about being more helpful and giving richer >information in our responses. Btw, just to clarify, when I used the word "anal" in my original comment, I wasn't trying to suggest your idea was anal or anything like that, just that there's a variety of status codes one could use depending on how close one wants to be to their "definitions" ---- >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. While to be fair, I think he's suggesting there still be a response body with detailed information. >If I login and get a 400 I can quickly deduce from the error code alone that >the username or password is wrong. I shouldn't have to resort to decoding the >response body to work out what went wrong... Or you forgot to supply a token (and possibly your client doesn't even know such a thing exists, so automatically interpreting 400 as login error would be incorrect). And logically speaking a "Access denied" error is not really the same as a "invalid parameter" error ------ >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. Yep, that sums up what I was trying to say pretty well. Also something I thought of right now, if the API has weird status codes, that could interfere with caching mechanisms (maxage and smaxage parameters of the api). On a similar note, returning 404 if the article is missing might be confusing to a client trying to establish if only the client is missing, or if the api itself is actually missing. ----- >The warnings are not error messages and just there for further information. A >developer doesn't need to worry about them. As far as I can tell the majority of the examples you have given are "warnings" not "errors" (and the login example is neither) -- 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
