[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