Update:API:UseCases 2.0
From MozillaWiki
Here are a few use cases and requested enhancement for the AMO API 2.0.
- Existing API 1.1 is documented here.
- Current Open API Bugs
Read Only API
stats
- Add API 1.0 stats back in per earlier requirements
- Add retrieval of stats for the entire site (cumulative downloads in period X & update pings in period X)
- As a test, write a sample PHP page that demos what an add-on author would do to embed their average daily active users & total downloads into their site
list enhancements
- Allow retrieval of category recommended add-ons. We currently allow only the retrieval of the featured list
- Add list add-ons from category X and of type Y
- Add missing type: lang pack
search
- Enhance "search" to allow some of the new advanced parameters to be included
sandbox/status/error details
- We currently don't show sandboxed add-ons thru the API. We should allow additional paramters to retrieve sandbox'ed add-on info
- Be able to find out for a particular add-on/add-on version what it's status is
- Right now, we don't report back errors, rather we simply send "not found". We should provide more status, e.g. "addon doesn't exist", "invalid parameters", "invalid date range", etc...
Write API
Setup/Admin
- Offer an API key signup system for developers
- Offer a stats page for summary usage by API key
- Allow bandwidth, throttling or hard limits on a per API key basis
- Allow disabling/revocation of an API key
- Allow some permission settings for API keys, e.g. devs can only update meta data for add-ons they own, localizers are allowed to change add-on AMO metadata strings
Updates & Uploads
- Allow AMO meta data updates (either base add-on properties or version-specific info updates). {Needs more specification}
- Allow new add-on file versions (JARs & XPIs) of existing add-ons to be submitted
- Allow review ratings for existing add-ons to be submitted
Sample Use Cases
- Add-on Update Publishing
- Developer has a sophisticated development cycle, with their own source code repo, alpha/beta test users. They are likely to be marked as trusted on AMO. They use AMO to simply publish and distribute their latest version. (think AdBlock Plus, Yahoo! Toolbar, NASA Night Launch, etc...)
- Questions: Do we build them a script that can upload? Do they need to build a front-end to tie into the API?
- Testing: Build a Perl/python script that uploads the latest version of a trusted add-on to the site. Is it a fully automated process?
- MozDev integration
- There are many add-on projects hosted on MozDev
- MozDev builds the front-end that allow one-button publishing to AMO. Form will collect required metadata and submit the info via the API
- Add-ons will likely not be published automatically (ie, not trusted)
- Individual API key are still required
- Localizer upload
- Add-on already exists on system and a localizer wants to upload translation strings for AMO add-on metadata
- Author site integration
- Author wants to offer on their site the ability to submit reviews/ratings to their add-on. Review/rating will show up on AMO
- This will definitely help sandboxed add-ons get more reviews/ratings so that they can become public
- Testing: Write sample code to show this might be done.