Last modified: 2011-03-13 18:05:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T14905, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12905 - Create a [[Special:Api]] to allow access of the Api through alternate syntax
Create a [[Special:Api]] to allow access of the Api through alternate syntax
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-04 08:24 UTC by Daniel Friesen
Modified: 2011-03-13 18:05 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Daniel Friesen 2008-02-04 08:24:27 UTC
A slightly useful addition to MediaWiki would be a special page method of accessing the API.

Basically through a query where rather than /api.php?a=1&b=2&c=3 you could use /wiki/Special:Api/a=1/b=2/c=3.

There are two explanatory uses for a Api special page:

The first one deals with not knowing where the Api exists.

When programming an extension, a external tool, or such. The location of the script root is not always known, however we will know the Short Url form, and be able to access a special page, or article on the wiki. But the API is not as easily accessed, because we can't find the location of api.php, since we don't even know if the wiki is using /api.php or /w/api.php or if they have it in a complete different root.

Of course, this issue isn't that hard to step over with an external tool where we can query for that info, or just force the user to specify where it is.

However that's not the case with the second issue. Interwiki links:

Interwiki links always give us a format that we can use to point to a page on another wiki, it doesn't matter if they are in short or long form we can point to a special page on another wiki. However, even doing a bunch of parsing of urls, we won't always even know how to find an api.php on the other wiki, in fact using short urls, we'll never correctly know.

The addition of a [[Special:Api]] would allow for extensions to be able to grab an interwiki url, and then grab data on the wiki on the other side of that interwiki link. Various things like stats, WikiText, or namespace info needed for transwiki stuff could be grabbed and used in a variety of ways for an extension.
Comment 1 Victor Vasiliev 2008-02-04 17:33:14 UTC
API and other raw pages may be accessed only from main entry point
Comment 2 Roan Kattouw 2008-02-04 17:55:15 UTC
(In reply to comment #1)
> API and other raw pages may be accessed only from main entry point
> 

That doesn't mean we can't do an HTTP 302 to it, does it? (Please correct me if I'm wrong, which would mean IE is even more brain-damaged than I give it credit for. CCing to Brion to check.)

Anyway, added [[Special:API]] in r30537, which just HTTP redirects to api.php. Stuff like [[Special:API/action=query&list=allpages&aplimit=5]] also works.
Comment 3 Daniel Friesen 2008-02-05 07:46:42 UTC
Ya, redirect was one of my thoughts.

Though, actually the reason why I suggested the / separation, is because of the differences in short and long urls.

With that setup, this would work:
/wiki/Special:API/action=query&list=allpages&aplimit=5
As it would redirect to something like:
/api.php?action=query&list=allpages&aplimit=5

However, long urls offer up:
/index.php?title=Special:Api/action=query&list=allpages&aplimit=5
Which will actually redirect to:
/api.php?action=query
Because the & is considered part of the actual query. It's also not possible to externally detect things like that, because it's possible that someone may be using path to query rewrites which do have the & issue, but no ? exists in the url.

That's why I suggested the / separated format where all the /'s would be replaced with &'s and put into the query. Because it works universally no matter what the setup.
Comment 4 Roan Kattouw 2008-02-05 14:32:08 UTC
(In reply to comment #3)
> Ya, redirect was one of my thoughts.
> 
> Though, actually the reason why I suggested the / separation, is because of the
> differences in short and long urls.
> 
> With that setup, this would work:
> /wiki/Special:API/action=query&list=allpages&aplimit=5
> As it would redirect to something like:
> /api.php?action=query&list=allpages&aplimit=5
> 
> However, long urls offer up:
> /index.php?title=Special:Api/action=query&list=allpages&aplimit=5
> Which will actually redirect to:
> /api.php?action=query
> Because the & is considered part of the actual query. It's also not possible to
> externally detect things like that, because it's possible that someone may be
> using path to query rewrites which do have the & issue, but no ? exists in the
> url.
> 
> That's why I suggested the / separated format where all the /'s would be
> replaced with &'s and put into the query. Because it works universally no
> matter what the setup.
> 

Slashes are also bad, because pagenames can contain slashes. Then again, they can also contain ampersands. It should be noted that ampersands did work when urlencoded.

Anyway, that's all moot now, because Brion reverted my commit. The path to api.php can be gotten quite easily through other means (like grabbing the wgScriptPath variable through JavaScript and appending /api.php).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links