[wp-meta] [Making WordPress.org] #6061: Download stats API returning unexpected results

[Making WordPress.org]

#6061: Download stats API returning unexpected results
--------------------+-----------------------
 Reporter:  pyves   |       Owner:  (none)
     Type:  defect  |      Status:  reopened
 Priority:  normal  |   Milestone:
Component:  API     |  Resolution:
 Keywords:          |
--------------------+-----------------------
Changes (by pyves):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 Replying to [comment:2 dd32]:
 > Don't use it for something it's not designed for, as all WordPress.org
 API endpoints are only intended on being used by WordPress or
 WordPress.org, they're not intended on being "public data API's", and may
 change their output format to suit requirements at any time.

 This answer is quite unexpected. I've got quite a few follow up questions:
 - https://codex.wordpress.org/WordPress.org_API is publicly accessible,
 there is no warning that is shouldn't be used, nor any explanation on what
 its intended purpose is. Why is that?
 - after a quick search through the support forum, I'm apparently not the
 first one to have stumbled upon this "public API" problem (e.g.
 https://wordpress.org/support/topic/using-the-wordpress-org-api/). Already
 at the time a suggestion was made to add a warning to the very same
 documentation, yet one of your colleagues refused to do so. Why is the
 WordPress.org team so keen on repeatedly misleading users?
 - you suggest using https://api.wordpress.org/plugins/info/1.0 instead of
 https://api.wordpress.org/stats/plugin/1.0/downloads deeming it "more
 standard and more acceptable to be used by others". Where is this
 documented? It seems arbitrary given that both endpoints are documented in
 the same place with nothing differentiating from a external user's
 perspective.
 - why is the API seemingly versioned (/1.0, /1.1, /1.2)? The idea behind
 API versioning is exactly to prevent output formats from changing
 unexpectedly, yet you're stating the opposite.

 Replying to [comment:3 dd32]:
 > Deal with the 'invalid' data if they provide invalid input

 How am I meant to deal with invalid data if there's no way to tell it's
 invalid? As noted by your colleague in
 https://core.trac.wordpress.org/ticket/54989, it's intentionally been
 faked, so there's not way to tell whether the returned numbers are real or
 not.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6061#comment:4>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org