-
Notifications
You must be signed in to change notification settings - Fork 984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document API policies #3333
Document API policies #3333
Changes from 4 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,6 +4,57 @@ API Reference | |
Warehouse has several API endpoints. See :doc:`../application` for the | ||
parts of Warehouse that generate them. | ||
|
||
.. contents:: :local: | ||
|
||
API Policies | ||
------------ | ||
|
||
Please be aware of the following PyPI API Policies: | ||
|
||
Caching | ||
~~~~~~~ | ||
|
||
All API requests are cached. Requests to the JSON, RSS or Legacy APIs are | ||
cached by our CDN provider. You can determine if you've hit the cache based on | ||
the ``X-Cache`` and ``X-Cache-Hits`` headers in the response. | ||
|
||
Requests to the JSON, RSS and Legacy APIs also provide an ``ETag`` header. If | ||
you're making a lot of repeated requests, please ensure your API consumer will | ||
respect this header to determine whether to actually repeat a request or not. | ||
|
||
The XML-RPC API does not have the ability to indicate cached responses. | ||
|
||
Rate Limiting | ||
~~~~~~~~~~~~~ | ||
|
||
Due to the heavy caching and CDN use, there is currently no rate limiting of | ||
PyPI APIs at the edge. The XML-RPC API may be rate limited if usage is causing | ||
degradation of service. | ||
|
||
In addition, PyPI reserves the right to temporarily or permanently prohibit a | ||
consumer based on irresponsible activity. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At a past org we suggested: use a descriptive User-Agent header with your contact info in it, so we can at least potentially ping you to suggest alternate approaches if you're causing a ruckus. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great point. |
||
|
||
If you plan to make a lot of requests to a PyPI API, please adhere to | ||
the following suggestions: | ||
|
||
* Set your consumer's ``User-Agent`` header to uniquely identify your requests. | ||
Adding your contact information to this value would be helpful as well. | ||
* Try not to make a lot of requests (thousands) in a short amount of time | ||
(minutes). Generally PyPI can handle it, but it's preferred to make requests | ||
in serial over a longer amount of time if possible. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suggest we add "consider running your own organizational mirror instead/in addition" & point to bandersnatch. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure that's good advice for folks that need consume our APIs. Does bandersnatch provide all the exact same APIs as PyPI? Generally I think "use bandersnatch" is good advice for users that either can't use (With the exception of using a mirror for the Simple/download API, which could be helpful in reducing load on our CDN, but I think we don't really have the assumption that this is necessary or recommended for big consumers -- we just handle the traffic.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This document tells API users how to be good neighbors, so I suggest we add a line advising orgs that it would be friendly for them to use internal mirrors for Simple/downloads. But my opinion is mild here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I found a happy medium 🙂 |
||
|
||
API Preference | ||
~~~~~~~~~~~~~~ | ||
|
||
For periodically checking for new packages or updates to existing packages, | ||
please use our RSS feeds. | ||
|
||
No new integrations should use the XML-RPC APIs as they are planned for | ||
deprecation. Existing consumers should migrate to JSON/RSS/Legacy APIs. | ||
|
||
Available APIs | ||
-------------- | ||
|
||
.. toctree:: | ||
:maxdepth: 2 | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need exception for XMLRPC here. At this point it provides no information about if the response was cached internally.