[wp-meta] [Making WordPress.org] #613: JSON output/endpoint(s) for profiles.wordpress.org

Making WordPress.org noreply at wordpress.org
Thu Sep 18 19:03:34 UTC 2014


#613: JSON output/endpoint(s) for profiles.wordpress.org
------------------------+----------------------
Reporter:  stephdau     |      Owner:
    Type:  enhancement  |     Status:  new
Priority:  normal       |  Component:  Profiles
Keywords:  needs-patch  |
------------------------+----------------------
 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
 ([http://codex.wordpress.org/WordPress.org_API 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. :)

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/613>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org


More information about the wp-meta mailing list