You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GitHub API has good support for conditional requests which will help prevent you from burning through your rate limit, as well as help speed up your application. go-github does not handle conditional requests directly, but is instead designed to work with a caching http.Transport. We recommend using gregjones/httpcache for that. For example:
I wanted to open an issue/discussion first before just opening a PR adding my library to the documentation as another option/recommendation, especially given it is not a RFC 7234 compliant cache. Instead it relies on (undocumented) GitHub API behavior to achieve a higher hit rate than a typical HTTP cache, in particular when combined with dynamic credentials such as a GitHub app.
However because it relies on undocumented behavior I wanted to collect any thoughts/input on recommending it first. The worse case behavior here is that if the ETag algorithm changes in the future, all requests will be become cache misses which is already the case if you are using dynamic credentials anyway...
The text was updated successfully, but these errors were encountered:
I'm happy to review a PR that updates the README.md in this repo to more clearly describe the current state of affairs and explain what your transport offers, how to get it, and how to use it.
Currently the go-github documentation suggests using the (archived) gregjones/httpcache library for conditional requests:
Recently, I've done some work reverse engineering the GitHub ETag algorithm and written a
*http.RoundTripper
that is specialized for the GitHub REST API. You can find more details/results in the README: https://github.com/bored-engineer/github-conditional-http-transportI wanted to open an issue/discussion first before just opening a PR adding my library to the documentation as another option/recommendation, especially given it is not a RFC 7234 compliant cache. Instead it relies on (undocumented) GitHub API behavior to achieve a higher hit rate than a typical HTTP cache, in particular when combined with dynamic credentials such as a GitHub app.
However because it relies on undocumented behavior I wanted to collect any thoughts/input on recommending it first. The worse case behavior here is that if the
ETag
algorithm changes in the future, all requests will be become cache misses which is already the case if you are using dynamic credentials anyway...The text was updated successfully, but these errors were encountered: