JSON output/endpoint(s) for profiles.wordpress.org

[stephdau]

Some co-workers and I are currently working on a project that would like to pull some profile data about WP developers from profiles.wordpress.org, which we currently have no means to do as a 3rd-party service (besides screen scraping).

I had a brief chat with Nacin about my volunteering to [help] make a JSON endpoint to get an individual developer's data by passing it a dev's WP.org username, and he was in favor of it, so here is my humble proposal and related questions. :)

Endpoint location (will define how it is written, bbpress vs BuddyPress):

• should this live under api.wordpress.org, as the theme, plugins, etc APIs, which I understand is bbpress and custom?
• or should it live under profiles.wordpress.org (be it a route or query string param), which would likely involve a small BuddyPress plugin instead?

My preference would be under api.wordpress.org:

• for general API consistency (​they all live there)
• to start with single dev output, but then be able to have a query interface as well (as is done for plugins, themes, etc).
• despite the fact I'd rather write a WP/BuddyPress plugin ;)
• I thought oembed would be neat, but it binds us to a standard schema that's not that useful for us versus the one I'll list below. Still something we could do (embed profile), but unlikely to be right for this project.

Original/default schema for the initial version:

• User editable data: display name, member since, etc.
• "Find me on" info (Gravatar verified services)
• Badges (plugin developer, etc).
• Time-based Sums from the other tabs (number of plugins, themes, comments, plugin commits, etc) in the last 1, 3 and 12 months (I currently have no clear concept of how heavy/bad those queries would have to be as I've not yet seen the backend for it).
• MD5 hash of email, aka Gravatar slug: this would let us easily verify if a person who on our end says they're such and such developer are indeed who they say they are (we'll have their email, and expect it to match the ones they used in their WP profile, as the latter does in regards to it being a Gravatar email).

I'm tagging this as "needs patch", but I'll of course provide the latter, once I have answers to the above questions. :)

[nacin]

I would just make it respond to ​http://profiles.wordpress.org/nacin.json.

There are exactly 2 user_logins that end in .json, and those will redirect to their user_nicename equivalents (old code to support when BuddyPress used to use user_logins in URLs for unknown reasons). So as long as the hook to serve application/json happens after that potential redirect, then you should be fine.

[Otto42]

Stuff on api.w is mostly used for talking to and supporting the WordPress core. Not that that is a requirement, but I'd probably put it on profiles.w.org instead. It's already running BuddyPress and has all the data you'd need there to serve it in whatever form you wanted. As a plugin it would probably be simpler to manage and maintain.

URL format = dealer's choice. Nacin's method is sound, but I'd probably want something more explicit if I were doing it. ?format=json or some such thing. Of course, both with a rewrite is an option as well.

[stephdau]

Works for me. Thanks for the feedback!

Also: MD5 hash of email: I just had a duh moment... Let's just make that field their Gravatar URL (currently displayed on front end), which will contains said hash (and be a grav :) ).

[nacin]

Replying to stephdau:

Works for me. Thanks for the feedback!

Also: MD5 hash of email: I just had a duh moment... Let's just make that field their Gravatar URL (currently displayed on front end), which will contains said hash (and be a grav :) ).

There's a wrinkle here, technically — ​http://www.gravatar.com versus ​https://secure.gravatar.com. You could pick one based on whether the request (which presumably would support JSONP and also have Access-Control-Allow-Origin: *, for the purposes of JS use) is over SSL or not. Also note that "subdomain" could be www, 0, 1, etc. Core actually does toggle between 0 and 1, but that's likely not necessary here. Barry's preference is 0 over www. (Also note, sharding should not be used for SSL requests as the handshake is slower.)

I just dealt with this for the plugins info endpoint but it should be a little easier as here you're not also trying to determine whether the admin is over SSL (not just the request).

[stephdau]

Nacin: Totally.

FYI: timeline: went through all of the thought process with my team this week, got a lot of feedback in person (Paul Gibbs, etc), and will produce the patch next week (traveling intensively this week).

[markoheijnen]

I did build something myself a few months ago what does screen scrapping and a bit more. See ​http://wpcentral.io/api/contributors/markoheijnen for an example.

[swissspidy]

I used screen scraping for ​WP Talents too and it's a pain. Especially since there's no way to fetch all activity entries of a user. WP Talents has an API on its own and even supports oEmbed. The code I use lives here: ​https://github.com/swissspidy/wptalents

Let me know I can help building a JSON API for this. What about building upon WP-API? Or is it unlikely to be activated on w.org anytime soon?

I've been dreaming of a "Log in using WordPress.org" button lately, but I doubt w.org will support oAuth in the future...

[SergeyBiryukov]

Removing 'needs-patch' from components that are not open sourced yet, to help focus on tickets that actually need a patch.

[ocean90]

#1736 was marked as a duplicate.

[ocean90]

#1737 was marked as a duplicate.

[Compute]

+1 for this.

Any update on this? Or how to help this ticket going forward?