I need to retrieve how many branches there are in a specified repository. If I call this
GET /repos/:owner/:repo/branches
I get the first 30, but I want them all
How do I tell the API to return everything? Or at least specify a different count to 30
The answer is to pass
?per_page=100&page=1
in the URL. 100 records at a time is the maximum.
https://developer.github.com/v3/#pagination
Related
I am trying to count the total number of contributors of a GitHub repository using the GitHub API. But, I did not get the exact number of contributors shown in the repository. For example, in the azure-sdk-for-go repository, the total number of contributors are shows as 188.
Now, if I run the below query, I get 157 as result.
def contributorCount(u, r):
return re.search('\d+$', requests.get('https://api.github.com/repos/{}/{}/contributors?per_page=1'.format(u, r)).links['last']['url']).group()
print(contributorCount("Azure", "azure-sdk-for-go"))
If I add the anon=True in the URL, then I got 169 contributors.
https://api.github.com/repos/{}/{}/contributors?per_page=1&anon=true
What am I missing here?
As noted in this discussion, it might not be trivial to find the same number:
A user can be “anonymous” if there is no GitHub user associated with a given email address.
And the reason that your number still may not match the one given by the UI is because the same GitHub user may have contributed using multiple email addresses. This is why I said above:
on larger repos, you may not be able to replicate the exact figure that we show on the website.
The API simply doesn’t return the information you need in order to be able to replicate the number we show.
I am trying to retrieve a list of all the files included in a pull request.
The Github API documentation in the following URL - https://developer.github.com/v3/pulls/#list-pull-requests-files mentions that it can retrieve a maximum of 300 files. However, when i run the request from Advanced Rest Client, i get a list of only 30 files.
Is there any way i could retrieve a list of all the files included in the pull request?
Github API paginates data in sets of 30 or 100 (depending on what you are requesting). You could consider increasing the per_page count to a higher value or just traverse through the pages. Ref: Github Pagination
There is /revisions API described here https://www.dropbox.com/developers/core/docs#revisions.
rev_limit Default is 10. Max is 1,000. When listing a file, the service won't report listings containing more than the amount specified and will instead respond with a 406 (Not Acceptable) status response.
Does it mean that if I will update file on my dropbox more than 1000 times then I wont be able to get any revision history of this file using DropBox Core API?
If there is a limit of 1000 revisions why this api wont just return LAST 1000 revisions instead of returning NOTHING when there is more than 1000 revisions??
In actuality, this endpoint will returned the most recent n revisions, up to rev_limit. I'm updating the documentation to match.
Explanation:
I am able to query the Google Core reporting APIv3 using the client library to get data on pageviews for specific URLs of a website I am working on. I want to get data(pageviews) for each day within a specified range. So far I am simply looping through the range, sending individual request to the API. in each request I am setting the same value for the start date and the end date.
Problem:
Obviously this gets the job done, BUT it is certainly not the best way to go about it. Because, assumming I want to get data for the past 3 months for each of about 2000 URIs. Then I will need 360000 number of requests and that value is well over the limit quota defined by Google.
Potential solution: So one way I thought of solving this issue is probably to send a request setting start-date and end-date to be a week apart but the API will return a sum of the values rather than the individual values.
main question: So is there a way to insist that these values should not be added up and returned as a sum but rather returned (as associative array or something like that) separately for each.
I hope the question is clear and that there is a solution! Thank you!
Very straightforward:
Metric: ga:pageview, Dimension: ga:date, Set a filter for your pagepath, and set a start-date and end-date.
Example:
https://www.googleapis.com/analytics/v3/data/ga?ids=ga%3Axxyyzz&dimensions=ga%3Adate&metrics=ga%3Apageviews&filters=ga%3Apagepath%3D%3D%2Ffaq.html&start-date=2013-06-27&end-date=2013-07-11&max-results=50
This will return the pageviews for that the faq.html& page for each day in the time-frame.
You should check out the QueryExplorer. Great tool to find out how to structure queries.
I'm fetching a large amount of comments from a public page using Facebook's Graph API.
By default facebook returns 25 comments per response, and uses paging. This causes the need for multiple requests, which is uneccesery as I know ahead there will be a lot of comments.
I read about the "limit" parameter that you can pass to ask for a certain amount of items per response.
I was wondering, what is the limit of that parameter? I'm assuming I can't pass &limit=10000.
There's a different way for fetching comments:
https://graph.facebook.com/<PAGE_ID>_<POST_ID>/comments?limit=500
The maximum value for the limit parameter is 500.
yes, with limit parameter you can pass what number of certain resource you want in one call. default limit is 25.
for ex. if you want 100 comment in one call for a post having id POST_ID, you can query like this:
https://graph.facebook.com/POST_ID?fields=comments.limit(100)
I think they have changed this. For /feed? I only get 200-225 posts back but for comments I get as many as 2000 back
Old question, but this is in the current Facebook documentation in case anyone finds this question via search (emphasis mine):
Some edges may also have a maximum on the limit value for performance reasons. In all cases, the API returns the correct pagination links.
In other words, even if you specify a limit above what's allowed by the endpoint, the "pagination.previous" and "pagination.next" elements will always provide the correct URL to resume where it left off.
I would recommend you to use FQL instead.
FQL provide a more flexible approach where you can combine data types (posts, users, pages, etc..) as you please. You can also query for comments belonging to a list of stories instead of just one limiting your number of requests even more.
There are a couple of drawbacks though:
1. There is a limit on 5000 comments. Here you would use a query looking something like: "SELECT id, ...... FROM comments, ... WHERE parent_id in (1,2,3....) ORDER BY time LIMIT 0, 5000". Even though you split this up in several queries with "LIMIT 0, 1000", "LIMIT 1000, 1000", LIMIT 2000, 1000, etc.., you would never get anything over 5000 comments("LIMIT 5000, 1000" would return empty).
2. All real requests made on Facebooks server counts as one request. You can send of something that is actually a combination of requests, this will be counted as multiple requests.
3. Facebook does not like to heavy requests. You can end up with getting blocked for a shorter time periods(minutes -> hours, not days). If this happens, act on it.