Once you have build your query we give you a copyable URL:
But if you are using mw.Api to make your call, as many users will be, you'd want this data in JSON format. We could also provide it in PHP plain object format.
Esanders | |
Mar 20 2016, 12:15 PM |
F5163320: pasted_file | |
Dec 27 2016, 12:09 PM |
F5163317: pasted_file | |
Dec 27 2016, 12:09 PM |
F3676224: pasted_file | |
Mar 20 2016, 12:15 PM |
Once you have build your query we give you a copyable URL:
But if you are using mw.Api to make your call, as many users will be, you'd want this data in JSON format. We could also provide it in PHP plain object format.
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
mediawiki/core | master | +28 -0 | ApiSandbox: Display params as JSON on request page |
You could as well make a case for Python (pywikibot), Perl, and every other
language in existence. Where is the line?
If you want to draw a line you could go with languages for which we provide a supported API in core.
But if you used a suitable UI component (e.g. dropdown) then I would have no objection to someone adding Python, Perl etc to that list.
So, none? Because the action API itself doesn't support any languages, it just supports input via HTTP GET or POST and provides output in a few different formats that can be parsed in many languages.
But if you used a suitable UI component (e.g. dropdown) then I would have no objection to someone adding Python, Perl etc to that list.
I would, because it's a bunch of additional complexity needed for something of rather limited utility.
I think it would be useful to show them formatted as JSON. JSON is not generally compatible with specific languages' syntax (even for JavaScript our coding conventions suggest different formatting of the quotes), but it's generally very easy to adjust with some search-and-replace.
Chromium dev tools has a option called "copy as CURL" in the network pane, which is a comparable feature. And I think providing copy-paste examples that devs can directly use will provide a much better developer experience (I most certainly would use it).
For Python, I think providing an example that uses the standard library (urllib.request) would be better, plus a link to other libraries/frameworks (https://www.mediawiki.org/wiki/API:Client_code#Python).
We can draw an arbitrary line by saying to be included as an example it has to be some ##% of API usage on the Wikimedia cluster.
Except there's no way to measure what programming language people are using to make their requests. Sometimes it's in User-Agent, but often enough it's not. Taking 161 agents that recently showed up in the api-feature-usage log as a random sample,
Maybe run a survey, or check what tags are used most often with MediaWiki-Action-API on Stackoverflow?
In general, it could be handled by a hook or other pluggable method since it might depend on the audience of the wiki. For Wikimedia wikis mw.Api (for gadget writers) and jQuery (which seems to get the most beginner question on SO) are the most obvious contenders IMO.
Clearly I don't mean the API protocol itself, we all know that's HTTP. We have a JavaScript library in MW core for making API calls (mediawiki.api.js), and a PHP one (ApiBase.phpApiMain.php), so there is a sensible place to draw a line.
+1
ApiBase isn't a library for calling the API, it's the base class for implementing the API.
It can be invoked directly to make derivative requests, so users writing code in core may need PHP object params. Regardless, coming up with a concrete way to define what should be listed shouldn't be a blocker - don't make perfect the enemy of good.
Change 328900 had a related patch set uploaded (by Esanders):
ApiSandbox: Display params as JSON on request page
We can deliberate on other formats later, but I think we're in agreement that JSON is neutral and definitely useful.
Change 328900 merged by jenkins-bot:
ApiSandbox: Display params as JSON on request page