I'm trying to perform a simple pagination based on time through a facebook endpoint. I was getting results that didn't match my since.
An example call <username>/statuses?since=1390176000
returns this pagination:
"paging": {
"previous": "https://graph.facebook.com/8489236245/statuses?since=1390500000&limit=25&__paging_token=<num>",
"next": "https://graph.facebook.com/8489236245/statuses?limit=25&until=1390250670&__paging_token=<num>"
}
My expected behavior was that after a query with since I will iterate on next till I reach NOW. But when doing the query they provide with until=1390250670 I actually get OLDER results. Is there any logical explanation for this? Should I just use the previous paging ?
As you are looking at the user's statuses, the pagination is reversed as the data is ordered in reverse chronological order. The newest entries are always on the first page, so paginating to the next page will always give you older entries.
Unfortunately, the Facebook documentation doesn't mention the ordering for this API call.
Related
I use facebook graph api and I encountered a problem relating to likes.
My request:
My goal is to find the count of the like. but the query timeout. What is the solution?
Thanx
My goal is to find the count of the like
So you only want the overall number of likes, the counter, but not the individual likes?
Then you should ask for the summary via field expansion:
/{page_id}/feed?fields=likes.limit(0).summary(1)
For each feed item, you will get a likes data structure that looks like this:
"likes": {
"data": [
],
"summary": {
"total_count": 12345
}
}
Try the options below.
Uncheck all the boxes and make the request again, if you give no error, go marking one by one until you find the problem.
Try not to use the limit (999999) is very, I've had problems trying to get as much information in one query page.
Make sure your access token created this with all the necessary permissions to your query.
I confess that I have never seen this error in the Graph API, is very generic and it is difficult to give you a more accurate suggestion.
is there any way to explore the Facebook Graph API by date range? Ex. to find all events on February?
I use following code, but I’m not sure, that’s correct request:
since=2015-01-28T00:00:00%2B0000&until=2015-01-30T00:00:00%2B00000
In this way, I get records for defined date range - ok, but there is missing events – a set is incomplete (despite it doesn’t exceed a limit of API). Why I can’t get all of results for given query?
Maybe do you know another method of filtering results by date?
thanks
There's no way to restrict the search results by since and until as far as I know.
For searching events, you can use the /search endpoint as described at
https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2#search
but I guess there's no further way to filter the results other than specifying the q parameter.
I am performing a rest call to facebooks search API using type=event
e.x.
search?fields=id,name,picture,owner,description,start_time,end_time,location,venue,updated_time,ticket_uri&q=concert&type=event
I have looked through the documentation and still have a few questions about specific pagination behavior of the event search API.
If I used a broad search term like "ma" and keep querying the pagination ['next'] URL would I cycle through all facebook events starting with "ma"? Does the pagination array give any indication when there are no more results to return?.
Do these searches include past events? If so is it possible to eliminate past events using the "since" parameter?
What is the maximum for the limit parameter?
Update:
As far as I can tell the number of pages you can get from a facebook search is limited to 500. This includes pages that can be accessed via pagination. In other words a query with limit >=500 will not return a pagination url, likewise a query with limit 250 will only return one pages worth of pagination.
You will "next page" until the count of results comes less then the limit
I'm not sure if that is possible using a simple Graph Request. Maybe using FQL
I don't know exactly. But i used a 2000 limit one day. And it worked.
Other doubts you can get answers testing your resquests with this tool
https://developers.facebook.com/tools/explorer/
I am also doing the same thing like you. I am collecting public post using graph search api.
When there are no results available or you reach max limit pagination section will not be there in response. So you can always check for paging is there in json response or not something like this.
NextResult = DeserJsonFBResponce.paging != null ? DeserJsonFBResponce.paging.next : string.Empty;
I am not so sure about this with events but for public post i am able to eliminate post using science and until parameters.
Maximum for the limit parameter is 2000 per get request.
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.
Why would there be a next AND previous link in the original search results?
Say for example:
https://graph.facebook.com/search?q=car&type=post&access_token=...
At the end of the first page of results you are able to page backwards and forwards? I would have expected to just go forwards then the next result page should have both previous and next.
...]
, "paging": {
"previous": "https://graph.facebook.com/search?q=car&type=post&access_token=...",
"next": "https://graph.facebook.com/search?q=car&type=post&access_token=..."
}
The next and previous on the initial query allows you to at a later time use the links to query the server for newer data then you had previously gotten.
This way you can request ONLY the new data, and have to parse ONLY the new data, and then you can elegantly shove the new data in with the already existing data that you had previously received.
This i presume is why they use a time stamp in the next and previous links as well instead of an offset.
Hope that helps.