Talk:Web APIs hub/Archive 2

About this board

Discuss the idea of having a "central place for third-party developers to access Wikimedia data sets and use our APIs".

Previous discussion was archived at Talk:Web APIs hub/Archive 1 on 2015-06-19.

Jdforrester (WMF) (talkcontribs)

[Posted by Verdy p in a wrong thread.]

@User:Jdforrester (WMF) Why do you refuse any mention about the Mediawiki UI API ("/w/index.php"), whose documentation is still missing but is required because it is used directly by the {{FULLURL:fullpagename|parameter=urlencodedvalue&...}} which is integrant part of MediaWiki syntax, but where its parameters are NOT the same than those supported by the "/w/api.php" API. Many of the API urls are also inserted in the rendered HTML pages by MediaWiki itself. This API is constantly visible in the navigation bar of any wiki while visiting it or using it (editing a page, showing the page history, listing "related changes" from the link in the side bar...).

It is really an API, mostly used interactively (by following links in the rendered pages), the only difference is that its parameters are simpler (by GET method only, and no POST data?) and the responses are not in JSON, but in HTML. It is even the most visible API and most used of Mediawiki. It must absolutely be documented !!! And it's definitely NOT the same as the "/w/api.php" API (not the same parameter names or values supported and very different response format).

The page where I tried to insert it had instructions saying "Feel free to add to the list below." and it is made to be updated constantly even for incomplete/missing documentation, because even these incomplete documentation are for interest of Mediawiki developers.

The purpose of this page is exactly to track the development of these documentations (in MediaWiki or any one of its core components or extensions). And various API docs had also been inserted for non-MediaWiki proprietary APIs (e.g. APIs from Google, Twitter, Facebook, LinkedIn, Bing, Reddit...). But you deleted my basic insertion twice (I used different forms) for this core function of MediaWiki itself...

Where is the "secret" that the Foundation (from which you are an employee) does not want to show to the Community? If you have relevant link to expose that documentation, then replace my addition by the relevant link, but persisting in hiding the existence of this API (existing in ALL installed instances of MediaWiki) is completely unproductive. For now, this page doies not even indicate the existence of this API and the need to maintain it documented (in some pages on this MediaWiki Wiki!)

This UI API also has privacy concerns (because it receives lot of user's browser data, such as cookies, configured prefered languages, referer URL, browser type/version, OS identifier, installed browser plugins, browser capabilities, accessibility features integrated in the browser, various unique identifiers generated by these plugins or the core browser itself, in addition to the user's IP, and HTML session identifiers generated by MediaWiki and reported by browsers in subsequent queries...) and how these infos are used by Mediawiki via this UI API is an important and legitimate concern for ALL users of MediaWiki.

Also this UI API has a companion API "/wiki/" which uses "rewrite rules" to simplify some URLs: one or more of the parameters may be rewritten in hierarchical form (it is most often but not always the target pagename, it is changed or augmented when the target is a "Special:*" page, which can rewrite aditional parameters) is also rewritten after the "/", others are left after the "?" in the query string). This rewritten form is used by all standard wikilinks. But this companion rewritten API is almost identical (may be with some restrictions, depending on the action parameter or the target page, notably its namespace, or usage restrictions notably by bots). It supports many (but not all) of the features proposed by the more extensive "/w/api.php" API (mostly used by bots, or by custom Mediawiki extensions including Lua scripts loaded via Scribunto), but changes the query and response format (no need of JSON encoding).

And even if this page is kept for "historical" interest, the UI API is there since ever and should be listed. Deprecating this page (when you added a notice just yesterday, after you cancelled my two attempts of inserting this indication) but not proposing any newer alternative is also a bad decision: please provide then a newer maintained page to visit within your recent notice. Not doing that means that your new notice is completely invalid and will be ignored by all users because they are offered no alternative.

Jdforrester (WMF) (talkcontribs)

@Verdy p This is an historic page about working to create a different page. It isn't active since 2015. I suggest you put your concerns at API talk:Web APIs hub.

Verdy p (talkcontribs)

Talk:Web APIs hub or API talk:Web APIs hub

Really what is the difference ? They talk about exactly the same thing! Only the namespace was changed (for the page) but talks continue on the same topic.

But even if the main page was changed in design, this UI API is still not there at all. It was true before the moving, and remains true today. There's still no doc to see anywhere about the UI API, that is historically the first one ever used and still the most widely used today!

Jdforrester (WMF) (talkcontribs)

If you cannot distinguish between a documentation page for readers, and a project page about creating the first, then I don't think this is the right wiki for you, sorry.

Verdy p (talkcontribs)

I don't have to make such distinction: this is a need for both (readers searching this documentation, and redactors of this missing documentation). In all cases this is still a valid "project" even today.

But if you want me to make such distinction for "talk pages", then there's no alternate talk page as well to report this issue, and this current talk page is appropriate.

And I'm on the RIGHT wiki to make such signal that the doc about a core feature of MediaWiki itself is evidently missing.

Quiddity (WMF) (talkcontribs)

Manual:Index.php already exists and is further documented at Manual:Parameters to index.php. It is currently linked from Manual:Contents (in the "Web access" section) and various other pages.

This project page is currently linked to from the bottom of API:Main_page as the place to find info on other APIs. We should probably either update that link to point elsewhere, or replace the link with the short-list that is currently in the never-completed documentation page at API:Web_APIs_hub.

However, I also do not know if "index.php" is technically/strictly-speaking an "API", so I'd be hesitant about what wording to use. I also don't know how often developers actually need to find that page, so I'm not sure how much it needs to be highlighted.

I'll also note that we're currently trying to hire a technical writer who will be partially working on this whole area, so I advise against any attempts at major changes until then.

Verdy p (talkcontribs)

This is still an API even if the result is in HTML form; it has query parameters (action=view/edit/purge/..., uselang=*= and some of them are non obvious; sometimes they are generated by core MediaWiki but it's difficult to locate them. Notably those related to "Special:*" pages, with some of them being rewritable in hierarchic form, but not always the same. When we look at the doc about Special pages, this is dificult to find, but they are essential to create some kinds of links that are not basic wikilinks, but some of them can be written as wikilinks without using FULLURL and a link within a span with class="plainlinks"). Examples of pages which can be linked with parameters prefilled in forms, and autorunning. I call this an API. And some of them are used directly by bots. Not all are special pages there are sometimes in the side bars or top bar. But there's no central repository and recommendations about how to extend these UI API (notably for Special pages or other Mediawiki plugins/hooks) or in the core functions of MediaWiki itself.

Reply to "[Verdy p's comment]"

It's very good to have a Flow page here...

3
Qgil-WMF (talkcontribs)

... because the new Developer Hub will have Flow enabled in all discussion pages, see phab:T103049.

ImperfectlyInformed (talkcontribs)
Quiddity (WMF) (talkcontribs)

That was the old test-instance, using the blueprint skin, but it seems to have been deleted recently (per). I've updated the page to remove mentions of that side-experiment.

There are no older topics
Return to "Web APIs hub/Archive 2" page.