Page MenuHomePhabricator

Write access policy for AQS docs
Open, Needs TriagePublic

Description

Write the access policy page for the AQS docs site

URL: /documentation/access-policy

Contents:

  • User-Agent instructions
  • link to terms
  • link to privacy policy
  • data licensing
  • rate limits
  • any other limitations we should call out from experience working with the dashboard
  • these datasets can also be downloaded via dumps.wikimedia.org/other/analytics/

Source:

Details

TitleReferenceAuthorSource BranchDest Branch
Update access policy - remove rate limitsrepos/generated-data-platform/aqs/analytics-api!28kbachno-rate-limitsmain
Add access policyrepos/generated-data-platform/aqs/analytics-api!11apaskulinaccessmain
Customize query in GitLab

Event Timeline

apaskulin added a subscriber: VirginiaPoundstone.

@VirginiaPoundstone For the rate limits for AQS 2.0, I've copied the per-endpoint rate limits from the RESTBase documentation. Looking at T341569: Add support for end-point (?) rate limiting on REST-Gateway, it seems like rate limiting may not be implemented yet in the REST Gateway, but I went ahead and listed the original rate limits since no other rate limits have been decided on at this time. Let me know if this works for you. We can always update them if we decide on a new set of limits.

Alternatively, we can use similar language as the MediaWiki APIs ("There is no fixed limit on requests to the API, but your client may be blocked if you endanger the stability of a site. To stay within a safe request rate, wait for each request to finish before sending another request.").

apaskulin added a subscriber: KBach.

This guide is now live! Moving to Sign Off and assigning to Virginia for a +1 on my previous comment: https://phabricator.wikimedia.org/T364799#9882524

@VirginiaPoundstone For the rate limits for AQS 2.0, I've copied the per-endpoint rate limits from the RESTBase documentation. Looking at T341569: Add support for end-point (?) rate limiting on REST-Gateway, it seems like rate limiting may not be implemented yet in the REST Gateway, but I went ahead and listed the original rate limits since no other rate limits have been decided on at this time. Let me know if this works for you. We can always update them if we decide on a new set of limits.

Alternatively, we can use similar language as the MediaWiki APIs ("There is no fixed limit on requests to the API, but your client may be blocked if you endanger the stability of a site. To stay within a safe request rate, wait for each request to finish before sending another request.").

I wondered where you got the rate limit stats from.

@SGupta please confirm that there is no rate limiting. If there is none, please outline work required to set one. I believe it would be a request to for rate limit to be applied in the RESTGatway, but want to confirm.

If there is no rate limiting, and we are not able to add it easily, then we should use the borrowed language: "There is no fixed limit on requests to the API, but your client may be blocked if you endanger the stability of a site. To stay within a safe request rate, wait for each request to finish before sending another request."

@VirginiaPoundstone I am not aware of any rate limits on AQS 2.0 service , tagging @hnowlan for confirmation.

@VirginiaPoundstone I am not aware of any rate limits on AQS 2.0 service , tagging @hnowlan for confirmation.

There are no currently configured rate limits in the REST Gateway.

Doc have been updated to use the more general language since there are no rate limits in place. This can be changed later if rate limits are put in place.