https://bugzilla.wikimedia.org/show_bug.cgi?id=38716
Brad Jorsch <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]. | |edu --- Comment #11 from Brad Jorsch <[email protected]> 2012-08-20 21:47:13 UTC --- IMO, the comparison to a RESTful API is fallacious since the MediaWiki API is ''not'' RESTful. In a RESTful API, for example, you'd not be able to specify multiple titles in the query or get back information on multiple titles beyond a "directory listing" of some sort. This is why RESTful API doesn't have this "some of the several resources you requested don't exist, some do, and some of the requests are malformatted" problems: it deals with one resource at a time. (In reply to comment #6) > (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). This, IMO, is a critical point. The API does not speak HTTP. It is using HTTP as a transport to return API results. Asking for the API to return an HTTP 404 message for the queried page being missing is like asking for a webserver to return an ICMP "Destination Unreachable" packet when a webpage is not found. (In reply to comment #10) > >Fundamentally I prefer strict apis to fuzzy ones - there is less room for > >error > >when writing code. > > I believe that's a separate issue though (Requesting that the api should fail > when asking for too many titles, vs this being about how the api should fail > [with an http status code]) IMO, this should be closed as WONTFIX and that filed as a separate feature request if Jon desires to follow up on it. OTOH, Jon could also easily enough have his framework check for warnings and treat them as errors. Note, BTW, that it's very possible for the API to return less than 50 results for certain requests (e.g. prop=revisions&rvprop=content when the individual revisions are very large) even though the "limit" parameter nominally supports 50 as a maximum. In this case, returning 400 and expecting the client to requery with the arbitrary lower limit seems unhelpful. -- 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
