Closed Bug 543559 Opened 15 years ago Closed 14 years ago

new API fields for v1.5

Categories

(addons.mozilla.org Graveyard :: API, enhancement, P1)

Product:
addons.mozilla.org Graveyard
Component:
API
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fligtar, Assigned: davedash)

References

Details

(Whiteboard: [z][r?clouserw][qa+]) 

The API should be extended to have the following:

# Ability to retrieve information on sandbox and self-hosted add-ons
# Contributions information, including a link to contribute, suggested amount, and Meet the Developers page
# Number of user reviews and link to view them
# Total downloads, weekly downloads, and latest daily user counts
# Add-on creation date
# Link to the developer's profile
# File size

Note that there are comments in the ZPP about whether the default should show sandbox/self-hosted add-ons by default. I don't want sandbox or self-hosted add-ons showing up in the current Add-ons Manager, as its lacks the UI to indicate that these are unreviewed and/or won't even have an install button. If someone wants to implement it such that the default shows everything but requests from the Add-ons Manager don't get them, that's fine, but just sounds like more work. I recommend defaulting to only public add-ons.
We need to be able to get the data on sandbox/self-hosted add-ons when doing single add-on lookups but they don't necessarily need to be in the search/recommended API calls, or at least not for the add-ons manager's needs. However the add-ons manager already does filter out any add-ons from those calls that don't have <status id="4"/> so maybe that is all we need anyway.
Whiteboard: [z]
The new API fields are going into the next version of the API.  Our first milestone will be parity with remora's API, and then we'll increment the version and add new features.
Assignee: nobody → dd
Severity: normal → enhancement
Depends on: 433361
Priority: P1 → P5
Target Milestone: 5.7 → 5.8
Sounds like this is a higher priority than the rest of the API.  Instead of /collections/ and friends, let's increment the API version and add these fields.
Priority: P5 → P1
Status: NEW → ASSIGNED
Whiteboard: [z] → [z][r?clouserw]
Whiteboard: [z][r?clouserw] → [z][r+clouserw]
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [z][r+clouserw] → [z][r=clouserw]
This can be seen on the new API 1.5.  An example here:

https://preview.addons.mozilla.org/z/en-US/firefox/api/1.5/addon/1865

I've filed bug 548361 to slightly change the output.  Other comments welcome - now is the time to make adjustments.
(In reply to comment #4)
> Other comments welcome - now is the time to make adjustments.

One thing that was discussed at the last Addons Manager meeting was displaying multiple screenshots. At the moment, there's only the URL to one thumbnail image. It'd be great to have a list of screenshot URLs, and URLs to their corresponding thumbnails. Bonus points for screenshot dimensions (and maybe thumbnail dimensions).

Also, I think the homepage/support URL of the addon is missing.
> One thing that was discussed at the last Addons Manager meeting was displaying
> multiple screenshots. At the moment, there's only the URL to one thumbnail
> image. It'd be great to have a list of screenshot URLs, and URLs to their
> corresponding thumbnails. Bonus points for screenshot dimensions (and maybe
> thumbnail dimensions).
> 
> Also, I think the homepage/support URL of the addon is missing.

Screenshots should be doable, dimensions, sadly are not stored in the db and therefore would require us to go to disk to find the dimensions.

homepage of the URL should also be doable.
Fligtar: does anyone else need to be cc'd to give feedback on the 1.5 API?
Can't think of anyone. Well, Bee might have some ideas for us.
As an actual API user, I'd like to see:

* Add-on ID, like <addon> -> <addon id="1865">
* Author ID, like <author> -> <author id="346">
* Alternative screenshots
* Author's comment
Some comments:

I think the way the file size is exposed is not ideal. I'd rather just see the full number of bytes, callers of the API can reformat that into kb or however they wish to display it.

Are the dates in any time zone or do we assume UTC?

The reviews URL doesn't appear to be a complete URL.

The meet the developers URL for contributions isn't a complete URL. Do you think it might also be a good idea to include the currency in the suggested amount?
> I think the way the file size is exposed is not ideal. I'd rather just see the
> full number of bytes, callers of the API can reformat that into kb or however
> they wish to display it.

We only store kb... so I'm hesitant to convert that to bytes since it would be inaccurate.  But I agree bytes would be better.  Should I just multiply by 1024?  We can always fix the file size data later.

> Are the dates in any time zone or do we assume UTC?

It's PST (because the DB is PST, not my choice) - but I can convert to UTC and slap on timezone info... or convert it to unixtime.  What would you prefer?
 
> The reviews URL doesn't appear to be a complete URL.
> The meet the developers URL for contributions isn't a complete URL. 

I will fix these.

> Do you
> think it might also be a good idea to include the currency in the suggested
> amount?

If we collected that, it would be good, but it is a string field, AFAIK.  If a developer wants to specify USD or EUR they can.
This is all good feedback.

> * Add-on ID, like <addon> -> <addon id="1865">
> * Author ID, like <author> -> <author id="346">
good idea

(In reply to comment #11)
> > I think the way the file size is exposed is not ideal. I'd rather just see the
> > full number of bytes, callers of the API can reformat that into kb or however
> > they wish to display it.
> 
> We only store kb... so I'm hesitant to convert that to bytes since it would be
> inaccurate.  But I agree bytes would be better.  Should I just multiply by
> 1024?  We can always fix the file size data later.

Sure

> > Are the dates in any time zone or do we assume UTC?
> 
> It's PST (because the DB is PST, not my choice) - but I can convert to UTC and
> slap on timezone info... or convert it to unixtime.  What would you prefer?
I'm not sure what happens when PST switches to DST - I guess the computer changes it's time and the database is none the wiser.  It wouldn't be a bad idea to convert these to UTC for the API.

> > Do you
> > think it might also be a good idea to include the currency in the suggested
> > amount?
> 
> If we collected that, it would be good, but it is a string field, AFAIK.  If a
> developer wants to specify USD or EUR they can.

This is a good idea.  It is just a string field and there are comments around it saying it's hardcoded to USD but it's a good idea to future proof this by adding the currency.  Hardcoding it is fine:   currency="USD"
(In reply to comment #11)
> > I think the way the file size is exposed is not ideal. I'd rather just see the
> > full number of bytes, callers of the API can reformat that into kb or however
> > they wish to display it.
> 
> We only store kb... so I'm hesitant to convert that to bytes since it would be
> inaccurate.  But I agree bytes would be better.  Should I just multiply by
> 1024?  We can always fix the file size data later.

Yeah I think that would be best though I'll try to remember it isn't accurate. Is it always going to be larger than reality or is it normally rounded?

> > Are the dates in any time zone or do we assume UTC?
> 
> It's PST (because the DB is PST, not my choice) - but I can convert to UTC and
> slap on timezone info... or convert it to unixtime.  What would you prefer?

Not sure it makes a big deal, just an epoch number is probably easiest to parse but a formatted string is fine anyway, but I would convert it to UTC. I guess in reality we aren't going to be displaying time info in the UI much anyway.
(In reply to comment #13)
> Not sure it makes a big deal, just an epoch number is probably easiest to parse
> but a formatted string is fine anyway, but I would convert it to UTC. I guess
> in reality we aren't going to be displaying time info in the UI much anyway.

Standard ISO format should work too - and that includes timezone infor (so may even be better?).


Something that hasn't been discussed yet is alpha/beta/official classifications of addon versions. Is this available in the API somehow? If not, can it be?
Alpha/Beta/etc...
Hmm... this only works if people use the release-channels

As for time, I'll do ISO format.
(In reply to comment #15)
> Alpha/Beta/etc...
> Hmm... this only works if people use the release-channels

So it's alpha/beta/stable/unclassified? That'd also work (possibly by assuming unclassified means stable, in the UI). Or is it more complicated than that?
Is it correct that the full previews are on pm-app-amo24 and the thumbnails on preview?
No, they should at least be the same.

I'll fix it tomorrow.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
mossop - it's displaying something based on configuration - I'll see why they aren't matched up, but it's not an issue for this bug.  So closing.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
At Krupa's request, here's the list of additional fields requested by the comments in this bug:

* Screenshot URLs and their thumbnail URLs
* Add-on homepage URL
* Add-on support URL
* Add-on ID added, like <addon> -> <addon id="1865">
* Author ID added, like <author> -> <author id="346">
* Developer comments
QA: This is going live in 5.8
Whiteboard: [z][r=clouserw] → [z][r=clouserw][qa+]
Comment # 0 says that Contributions info including a link to contribute should be made available in the API

STR:
1.Search for add-on: WOT(https://preview.addons.mozilla.org/en-US/firefox/addon/3456) in the API

expected results:
Contribution information is available in the API

https://preview.addons.mozilla.org/en-US/firefox/api/1.2/addon/3456

Reopening for clarification.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #23)
> Comment # 0 says that Contributions info including a link to contribute should
> be made available in the API
> 
> STR:
> 1.Search for add-on:
> WOT(https://preview.addons.mozilla.org/en-US/firefox/addon/3456) in the API
> 
> expected results:
> Contribution information is available in the API
> 
> https://preview.addons.mozilla.org/en-US/firefox/api/1.2/addon/3456
> 
> Reopening for clarification.


Please be mindful of the API version.  The new fields will only be in /api/1.5 (although new attributes are in all versions).
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Flags: in-litmus?
I don't see either the add-on homepage URL [1] or the add-on support URL [2] for Adblock Plus:

https://preview.addons.mozilla.org/z/en-US/firefox/api/1.5/addon/1865

[1] http://adblockplus.org/
[2] http://adblockplus.org/forum/
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Whiteboard: [z][r=clouserw][qa+] → [z][r?clouserw][qa+]
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
(In reply to comment #25)
> I don't see either the add-on homepage URL [1] or the add-on support URL [2]
> for Adblock Plus:
> 
> https://preview.addons.mozilla.org/z/en-US/firefox/api/1.5/addon/1865
> 
> [1] http://adblockplus.org/
> [2] http://adblockplus.org/forum/

And I do, now; bizarre.  WTF is going on?
davedash fixed comment 25 earlier today, as evidenced by the awesome Jetpack (Ehsan's!) which shows me what Bugzilla doesn't, by default :-)  All's good, here.
Comment #23:

https://preview.addons.mozilla.org/z/en-US/firefox/api/1.5/addon/3456

expected result: Contribution information is available in the API 1.5

actual result:Contribution information is not available

Comment #0 says:
# Number of user reviews and link to view them
# Total downloads, weekly downloads, and latest daily user counts
# Add-on creation date
# Link to the developer's profile
# File size

Also following are not listed:
-author id
-reviews and the reviews link
-Downloads information and daily user counts
-developer profile link
-Created date
I believe that comment 21 supercedes comment 0, but I could be wrong.

Also, I definitely see:

* <author id="18970">
* <reviews num="509">https://preview.addons.mozilla.org/z/en-US/firefox/addon/3456/reviews/?src=api</reviews>
* <meet_developers>https://preview.addons.mozilla.org/z/en-US/firefox/addon/3456/developers?src=api</meet_developers>
* <created epoch="1159334220">2006-09-27 05:17:00+0000</created>

Not sure why you're not seeing those; maybe it was temporary?
I spun off comment 28 as bug 554446; verified FIXED, as when it's working (without that bug), we see all the fields show up properly.
Status: RESOLVED → VERIFIED
Dave or Justin, can you provide a link to the checkin of the new code? I would like to know regarding my work on bug 558287. Thanks.
Summary: new API fields → new API fields for v1.5
Blocks: 551274
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.