Hi there team -
We're interested in pulling together API needs from mobile web and apps. I know there have been various Bugzilla/Phabricator tasks, public list threads, and so on (and some projects, like the one Bernd has been speerheading). That said, would people please add links at the following page to help centralize this information?
https://www.mediawiki.org/wiki/Wikimedia_Reading/Mobile_needs_from_MediaWiki...
The purpose of this is to start planning ahead for coordination especially with Brad Jorsch - Mr. API! - on the Reading team.
-Adam
Hey Adam,
There's a tracking task which lists many tasks of this nature, although it's not exhaustive: https://phabricator.wikimedia.org/T75616
It occurs to me that there's also some stuff that was made recently and put in the backlog that should also be on this task. I'll add those tasks too.
Dan
On 22 April 2015 at 21:33, Adam Baso abaso@wikimedia.org wrote:
Hi there team -
We're interested in pulling together API needs from mobile web and apps. I know there have been various Bugzilla/Phabricator tasks, public list threads, and so on (and some projects, like the one Bernd has been speerheading). That said, would people please add links at the following page to help centralize this information?
https://www.mediawiki.org/wiki/Wikimedia_Reading/Mobile_needs_from_MediaWiki...
The purpose of this is to start planning ahead for coordination especially with Brad Jorsch - Mr. API! - on the Reading team.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I'll be setting a meeting with engineers from Reading to go over API / Services stuff - the plan being to figure out where we want to be in a year, and then work backward.
-Adam
On Wed, Apr 22, 2015 at 9:37 PM, Dan Garry dgarry@wikimedia.org wrote:
Hey Adam,
There's a tracking task which lists many tasks of this nature, although it's not exhaustive: https://phabricator.wikimedia.org/T75616
It occurs to me that there's also some stuff that was made recently and put in the backlog that should also be on this task. I'll add those tasks too.
Dan
On 22 April 2015 at 21:33, Adam Baso abaso@wikimedia.org wrote:
Hi there team -
We're interested in pulling together API needs from mobile web and apps. I know there have been various Bugzilla/Phabricator tasks, public list threads, and so on (and some projects, like the one Bernd has been speerheading). That said, would people please add links at the following page to help centralize this information?
https://www.mediawiki.org/wiki/Wikimedia_Reading/Mobile_needs_from_MediaWiki...
The purpose of this is to start planning ahead for coordination especially with Brad Jorsch - Mr. API! - on the Reading team.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation
master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'
javascripts/modules/editor/EditorApi.js
67: // FIXME: MediaWiki API, seriously?
73: // FIXME: API - missing is set to empty string (face palm)
183: // FIXME: AbuseFilter should have more consistent API responses
javascripts/modules/gallery/PhotoListApi.js
76: // FIXME: [API] have to request timestamp since api returns an object
116: // FIXME: [API] in an ideal world imageData would be a sorted array
124: // FIXME: API I hate you.
javascripts/modules/nearby/NearbyApi.js
144: // FIXME: API bug 48512
153: // FIXME: API returns object when array would make much sense
javascripts/modules/uploads/PhotoApi.js
253: // FIXME: API doesn't return this information on duplicate images...
resources/mobile.mediaViewer/ImageApi.js
54: // FIXME: API
resources/mobile.startup/PageApi.js
148: // FIXME: [API] the API sometimes returns an object and sometimes an array
211: // FIXME: API returns an object when a list makes much more sense
215: // FIXME: "|| []" wouldn't be needed if API was more consistent
Great thinking, Jon! I'm sure that didn't even catch everything. I know there are some comments like that in the iOS repo, but aren't as easy to detect.
Would be great if each client had a system for flagging & cataloging this kind of tech debt.
On Wed, Apr 29, 2015 at 2:03 PM, Jon Robson jdlrobson@gmail.com wrote:
master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'
javascripts/modules/editor/EditorApi.js
67: // FIXME: MediaWiki API, seriously?
73: // FIXME: API - missing is set to empty string (face palm)
183: // FIXME: AbuseFilter should have more consistent API responses
javascripts/modules/gallery/PhotoListApi.js
76: // FIXME: [API] have to request timestamp since api returns an object
116: // FIXME: [API] in an ideal world imageData would be a sorted array
124: // FIXME: API I hate you.
javascripts/modules/nearby/NearbyApi.js
144: // FIXME: API bug 48512
153: // FIXME: API returns object when array would make much sense
javascripts/modules/uploads/PhotoApi.js
253: // FIXME: API doesn't return this information on duplicate images...
resources/mobile.mediaViewer/ImageApi.js
54: // FIXME: API
resources/mobile.startup/PageApi.js
148: // FIXME: [API] the API sometimes returns an object and sometimes an array
211: // FIXME: API returns an object when a list makes much more sense
215: // FIXME: "|| []" wouldn't be needed if API was more consistent
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
A simple first step would be to tag the FIXMEs with a small set of tags, like half of Jon's examples already are.
–Sam
On Wed, Apr 29, 2015 at 7:10 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
Great thinking, Jon! I'm sure that didn't even catch everything. I know there are some comments like that in the iOS repo, but aren't as easy to detect.
Would be great if each client had a system for flagging & cataloging this kind of tech debt.
On Wed, Apr 29, 2015 at 2:03 PM, Jon Robson jdlrobson@gmail.com wrote:
master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'
javascripts/modules/editor/EditorApi.js
67: // FIXME: MediaWiki API, seriously?
73: // FIXME: API - missing is set to empty string (face palm)
183: // FIXME: AbuseFilter should have more consistent API responses
javascripts/modules/gallery/PhotoListApi.js
76: // FIXME: [API] have to request timestamp since api returns an object
116: // FIXME: [API] in an ideal world imageData would be a sorted array
124: // FIXME: API I hate you.
javascripts/modules/nearby/NearbyApi.js
144: // FIXME: API bug 48512
153: // FIXME: API returns object when array would make much sense
javascripts/modules/uploads/PhotoApi.js
253: // FIXME: API doesn't return this information on duplicate images...
resources/mobile.mediaViewer/ImageApi.js
54: // FIXME: API
resources/mobile.startup/PageApi.js
148: // FIXME: [API] the API sometimes returns an object and sometimes an array
211: // FIXME: API returns an object when a list makes much more sense
215: // FIXME: "|| []" wouldn't be needed if API was more consistent
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Personally, I would love hand crafted awesome documentation and full versions of the API. From developers, to developers, with care.
As an example, the github api is very good: https://developer.github.com/v3/issues/ for example.
And for me the gold in api docs is the stripe ones : https://stripe.com/docs/api/curl#retrieve_customer So useful, calling and responses examples in several languages, OHH so good.
Such a pleasure to read and use and the confidence that if you are using a version, it's not going to change under your feet.
On Thu, Apr 30, 2015 at 10:06 AM, Sam Smith samsmith@wikimedia.org wrote:
A simple first step would be to tag the FIXMEs with a small set of tags, like half of Jon's examples already are.
–Sam
On Wed, Apr 29, 2015 at 7:10 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
Great thinking, Jon! I'm sure that didn't even catch everything. I know there are some comments like that in the iOS repo, but aren't as easy to detect.
Would be great if each client had a system for flagging & cataloging this kind of tech debt.
On Wed, Apr 29, 2015 at 2:03 PM, Jon Robson jdlrobson@gmail.com wrote:
master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'
javascripts/modules/editor/EditorApi.js
67: // FIXME: MediaWiki API, seriously?
73: // FIXME: API - missing is set to empty string (face palm)
183: // FIXME: AbuseFilter should have more consistent API responses
javascripts/modules/gallery/PhotoListApi.js
76: // FIXME: [API] have to request timestamp since api returns an object
116: // FIXME: [API] in an ideal world imageData would be a sorted array
124: // FIXME: API I hate you.
javascripts/modules/nearby/NearbyApi.js
144: // FIXME: API bug 48512
153: // FIXME: API returns object when array would make much sense
javascripts/modules/uploads/PhotoApi.js
253: // FIXME: API doesn't return this information on duplicate images...
resources/mobile.mediaViewer/ImageApi.js
54: // FIXME: API
resources/mobile.startup/PageApi.js
148: // FIXME: [API] the API sometimes returns an object and sometimes an array
211: // FIXME: API returns an object when a list makes much more sense
215: // FIXME: "|| []" wouldn't be needed if API was more consistent
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
+S (not sure if you're on this list)
On Thu, Apr 30, 2015 at 3:27 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
Personally, I would love hand crafted awesome documentation and full versions of the API. From developers, to developers, with care.
As an example, the github api is very good: https://developer.github.com/v3/issues/ for example.
And for me the gold in api docs is the stripe ones : https://stripe.com/docs/api/curl#retrieve_customer So useful, calling and responses examples in several languages, OHH so good.
Such a pleasure to read and use and the confidence that if you are using a version, it's not going to change under your feet.
On Thu, Apr 30, 2015 at 10:06 AM, Sam Smith samsmith@wikimedia.org wrote:
A simple first step would be to tag the FIXMEs with a small set of tags, like half of Jon's examples already are.
–Sam
On Wed, Apr 29, 2015 at 7:10 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
Great thinking, Jon! I'm sure that didn't even catch everything. I know there are some comments like that in the iOS repo, but aren't as easy to detect.
Would be great if each client had a system for flagging & cataloging this kind of tech debt.
On Wed, Apr 29, 2015 at 2:03 PM, Jon Robson jdlrobson@gmail.com wrote:
master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'
javascripts/modules/editor/EditorApi.js
67: // FIXME: MediaWiki API, seriously?
73: // FIXME: API - missing is set to empty string (face palm)
183: // FIXME: AbuseFilter should have more consistent API responses
javascripts/modules/gallery/PhotoListApi.js
76: // FIXME: [API] have to request timestamp since api returns an object
116: // FIXME: [API] in an ideal world imageData would be a sorted array
124: // FIXME: API I hate you.
javascripts/modules/nearby/NearbyApi.js
144: // FIXME: API bug 48512
153: // FIXME: API returns object when array would make much sense
javascripts/modules/uploads/PhotoApi.js
253: // FIXME: API doesn't return this information on duplicate images...
resources/mobile.mediaViewer/ImageApi.js
54: // FIXME: API
resources/mobile.startup/PageApi.js
148: // FIXME: [API] the API sometimes returns an object and sometimes an array
211: // FIXME: API returns an object when a list makes much more sense
215: // FIXME: "|| []" wouldn't be needed if API was more consistent
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
A little tangential, and maybe it goes without saying, but I really like that MediaWiki API points to documentation in-band when fetched via browser (without the format option). For example:
https://en.wikipedia.org/w/api.php?action=query&prop=pageimages&pipr...
Although a nice improvement would be to link to the specific API used.
--Stephen
On Thu, Apr 30, 2015 at 6:00 PM, Jon Katz jkatz@wikimedia.org wrote:
+S (not sure if you're on this list)
On Thu, Apr 30, 2015 at 3:27 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
Personally, I would love hand crafted awesome documentation and full versions of the API. From developers, to developers, with care.
As an example, the github api is very good: https://developer.github.com/v3/issues/ for example.
And for me the gold in api docs is the stripe ones : https://stripe.com/docs/api/curl#retrieve_customer So useful, calling and responses examples in several languages, OHH so good.
Such a pleasure to read and use and the confidence that if you are using a version, it's not going to change under your feet.
On Thu, Apr 30, 2015 at 10:06 AM, Sam Smith samsmith@wikimedia.org wrote:
A simple first step would be to tag the FIXMEs with a small set of tags, like half of Jon's examples already are.
–Sam
On Wed, Apr 29, 2015 at 7:10 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
Great thinking, Jon! I'm sure that didn't even catch everything. I know there are some comments like that in the iOS repo, but aren't as easy to detect.
Would be great if each client had a system for flagging & cataloging this kind of tech debt.
On Wed, Apr 29, 2015 at 2:03 PM, Jon Robson jdlrobson@gmail.com wrote:
master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'
javascripts/modules/editor/EditorApi.js
67: // FIXME: MediaWiki API, seriously?
73: // FIXME: API - missing is set to empty string (face palm)
183: // FIXME: AbuseFilter should have more consistent API responses
javascripts/modules/gallery/PhotoListApi.js
76: // FIXME: [API] have to request timestamp since api returns an object
116: // FIXME: [API] in an ideal world imageData would be a sorted array
124: // FIXME: API I hate you.
javascripts/modules/nearby/NearbyApi.js
144: // FIXME: API bug 48512
153: // FIXME: API returns object when array would make much sense
javascripts/modules/uploads/PhotoApi.js
253: // FIXME: API doesn't return this information on duplicate images...
resources/mobile.mediaViewer/ImageApi.js
54: // FIXME: API
resources/mobile.startup/PageApi.js
148: // FIXME: [API] the API sometimes returns an object and sometimes an array
211: // FIXME: API returns an object when a list makes much more sense
215: // FIXME: "|| []" wouldn't be needed if API was more consistent
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
(adding Brad Jorsch)
On Thu, Apr 30, 2015 at 11:16 PM, Stephen Niedzielski < sniedzielski@wikimedia.org> wrote:
A little tangential, and maybe it goes without saying,
It took programming from Brad Jorsch and others, so thanks for noticing!
but I really like that MediaWiki API points to documentation in-band when fetched via browser (without the format option). For example:
https://en.wikipedia.org/w/api.php?action=query&prop=pageimages&pipr...
Although a nice improvement would be to link to the specific API used.
Nice idea,I filed T97842 https://phabricator.wikimedia.org/T97842. ApiHelp.php code would have to work from the query modules in the URL to the requesting module's help. In this case https://en.wikipedia.org/w/api.php?action=help&modules=query%2Bpageimage...
Pro tip: you can take any api.php request and load it into Special:ApISandbox by turning the query string into a URL fragment. So take the above and replace /w/api.php? with /wiki/Special:ApiSandbox# , and https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=pagei...
Maybe pretty-printed API results could add a [try in ApiSandbox] link similar to the one I added to the {{ApiEx}} wiki template.
I noticed pageimages doesn't show a (read more https://www.mediawiki.org/wiki/API:Properties#linkshere_.2F_lh) link to its wiki doc,I filed T97835 https://phabricator.wikimedia.org/T97835.
Stephen, welcome! FYI I wrote an article about search results and pageimages for the upcoming (or dead-by-reorg :) ) "Data and developer hub", https://www.mediawiki.org/wiki/API:Page_info_in_search_results (Monte, how's the review coming :-) ?).