Last modified: 2013-01-30 21:20:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 31629 - API uses weird * (star/asterisk) key for the content property in JSON and PHP serialized formats
API uses weird * (star/asterisk) key for the content property in JSON and PHP...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Lowest trivial (vote)
: ---
Assigned To: Yuri Astrakhan
:
: 42888 (view as bug list)
Depends on:
Blocks: api-2.0
  Show dependency treegraph
 
Reported: 2011-10-12 00:27 UTC by Ryan Kaldari
Modified: 2013-01-30 21:20 UTC (History)
14 users (show)

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


Attachments

Description Ryan Kaldari 2011-10-12 00:27:35 UTC
http://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Hello+World&rvlimit=1&rvprop=content%7Ctimestamp&format=json

returns:

{"timestamp":"2011-10-11T23:54:33Z","*":"A '''\"Hello world\" program''' is a [[computer program]] that prints out \"Hello world\" on...."}

for the query.pages[0].page.revisions[0]

Why is it assigning the content to a key called "*"?? This is unfortunate since * is an operator in Javascript, so you can't use the normal query.pages[0].page.revisions[0].*, and instead have to use query.pages[0].page.revisions[0]['*']. Why don't we assign it to a key called "rev" like in the XML version, or better yet "content" (the name of the property)? All of the other properties have regular key names so why not the content? Otherwise we are just giving JS developers a headache.
Comment 1 Max Semenik 2011-10-12 06:02:25 UTC
I'm afraid that too many people already use *, we can't change it without a major b/c breakage.
Comment 2 Ryan Kaldari 2011-10-14 01:35:11 UTC
That's the reply I get for every API bug I file. Can't we have an API 2.0 keyword or something? Right now our API is virtually unusable without a framework, unless you have a lot of time on your hands to figure out all the weird result cases (for example, boolean true returned as an empty string). At some point it would be nice if we created a clean API from scratch and launched it as an alternative and then gradually phased out the old API.
Comment 3 MZMcBride 2011-10-14 02:32:00 UTC
(In reply to comment #2)
> That's the reply I get for every API bug I file. Can't we have an API 2.0
> keyword or something?

Versioning the API might be possible, yes. That'd be a separate bug, though.

> Right now our API is virtually unusable without a
> framework, unless you have a lot of time on your hands to figure out all the
> weird result cases (for example, boolean true returned as an empty string). At
> some point it would be nice if we created a clean API from scratch and launched
> it as an alternative and then gradually phased out the old API.

Maybe. The API should be stable. The fact that developers aim for stability is a feature, not a bug. Being required to put quotes around special operators in a programming language doesn't seem like a huge deal to me. Most languages require some escaping, don't they? & in HTML, for example. Is "*" a fairly poor name? Yes, I think so. It'd be interesting to figure out why it was picked (perhaps there's a logical, rational reason, you can check SVN), but hindsight is always going to be 20/20. Sometimes you have to make do with a bit of imperfection. If the use of "*" is causing actual bugs somewhere, that'd be a different story.

A version URL parameter might be feasible (I don't think a bug has been filed about this already, feel free to search/submit), but you also shouldn't expect no objections to it. Versioning adds a significant amount of code complexity, of course. Some people might be hesitant. Simply because people disagree with you on Bugzilla doesn't mean they're right. Sometimes it's simply a matter of making a better case. :-)

In any case, even with a version parameter, the default will likely always use "*" to avoid backward-compatibility issues, so this seems like a valid wontfix to me.
Comment 4 Roan Kattouw 2011-10-25 14:54:52 UTC
(In reply to comment #3)
> It'd be interesting to figure out why it was picked
> (perhaps there's a logical, rational reason, you can check SVN), but hindsight
> is always going to be 20/20. Sometimes you have to make do with a bit of
> imperfection. If the use of "*" is causing actual bugs somewhere, that'd be a
> different story.
> 
When the API was designed in 2006, XML was cool, so the API was primarily designed for XML output. Other output formats seem to have been added as an afterthought. In the years that followed, the world (or most of it, anyway), realized XML is an inflexible piece of garbage and moved to JSON. However, we're still stuck with the legacy of having to support XML which means that 1) we can't do certain things in JSON because they can't be translated to XML and 2) we have things like the * thing that look good in XML and look like crap in every other format on the planet.

I used to think the multi-format thing was cool, but I am now of the opinion that an API 2.0 should output JSON only. It's the only format worth bothering with, the others all suck to varying degrees.
Comment 5 Max Semenik 2011-10-25 17:10:41 UTC
Oh, there are plans for API 2.0?
Comment 6 Roan Kattouw 2011-10-25 17:12:48 UTC
(In reply to comment #5)
> Oh, there are plans for API 2.0?
No, not really. I should probably have said something like "any API 2.0 project, if and when it happens".
Comment 7 Max Semenik 2011-10-28 05:15:49 UTC
I would really love to see most of our current formats go away:
* I have no doubts that nobody uses wddx, txt and dump formats (some of them could be useful for debugging, but jsonfm is no less readable for this purpose)
* While there can be existing YAML users, they should really use something less stillborn.
* And dbg format with its advice to "Use PHP's eval() function to recover data" is especially evil.
Comment 8 Daniel Friesen 2011-10-28 05:43:10 UTC
(In reply to comment #7)
> I would really love to see most of our current formats go away:
> * I have no doubts that nobody uses wddx, txt and dump formats (some of them
> could be useful for debugging, but jsonfm is no less readable for this purpose)
> * While there can be existing YAML users, they should really use something less
> stillborn.
> * And dbg format with its advice to "Use PHP's eval() function to recover data"
> is especially evil.

Aye, even .plist (iirc has an easier API to work with data in iOS than JSON) would be more useful than most of those formats.
Comment 9 Waldir 2012-12-09 16:01:22 UTC
*** Bug 42888 has been marked as a duplicate of this bug. ***
Comment 10 Waldir 2012-12-09 16:05:33 UTC
The discussion above seems unanimous in admiting * was a poor naming choice and only supported for legacy reasons. How hard would it be to make the API output version strings? I mean without actually implementing any new features yet (such as dumping rarely used formats, etc).
Comment 11 Yuri Astrakhan 2013-01-30 20:07:28 UTC
Part of APIv2. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future#Cleanup
Comment 12 Ryan Kaldari 2013-01-30 20:18:35 UTC
The future looks bright! One question though: Why use '_' (which is a bit cryptic), rather than some generic word like 'content'? FWIW, Flickr's API uses '_content'.
Comment 13 Yuri Astrakhan 2013-01-30 21:20:43 UTC
I'm all for it - we have been discussing the name - see discussion page at http://www.mediawiki.org/wiki/Talk:Requests_for_comment/API_Future - just need a name that doesn't conflict with all the other fields that API and extensions generate.

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


Navigation
Links