https://bugzilla.wikimedia.org/show_bug.cgi?id=38891
--- Comment #8 from Roan Kattouw <[email protected]> 2012-08-24 19:18:51 UTC --- (In reply to comment #7) > A few comments: > * While RESTfulish URLs look nice, MW is supposed to work without rewrites AND > pathinfo, so I guess we'll have to stick with api.php?foo=bar Yes. > * Formats: my main concern is format=xml WHICH SHOULD BE KILLED WITH FIRE, YEESSS. I'd like JSON to be the only format just so we can get rid of all the formatting differences, but really what I care most about is for XML output to die in a fire already. > * Prop is a useful thing when you're requesting a shitload of information, > especially when you're not on broadband. Also, some props require additional > computations, so better exclude them if not needed. For example, I can't > imagine action=parse without fine-grained props. Absolutely. (In reply to comment #5) > * Request-header based formatting (instead of format=json, use "Accept: > application/json", like $.ajax({ dataType: "json" }) already does. Optionally > still allowing an override, though I don't think that should be necessary. Or > alternatively drop all non-JSON formats as of API 2.0, may sound radical but I > think its perfectly reasonable). One feature of the existing API that should be a design goal of the new one is that it doesn't rely on any fancy HTTP features, so you can write an API client even if you can't: * use HTTP methods other than GET and POST (e.g. JavaScript) * set custom HTTP headers * read custom HTTP headers * read HTTP status codes The API could *optionally* communicate things using these things (we currently set the X-API-Error header for instance), but you should be able to use it just as well without them. So per that rule, formatting based on Accept: is evil unless &format= is also kept around. I also like the idea of just making it JSON-only. > * Less complicated responses > - don't wrap everything in { <actionname>: } You need to if you allow multiple actions (which I think we should). > - always include all properties, the <>prop thing is very annoying imho It's good for filtering per comment 7, although the defaults could be tweaked. > * Simple directory-like urls (either through rewriting or with path info) > Evil because it reduces flexibility in terms of requesting multiple things at the same time, and requires path info. See also comment 6 and comment 7. -- 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
