I can't get Facebook to return the page like count, the response provided does not match what the API states. According to the docs, the following URL:
https://graph.facebook.com/v2.10/<page-id>/likes?access_token=<access-token>&summary=true
should return a JSON response with a summary key that provides the like count in the corresponding hash. The problem is the response never contains the summary key, but it does contain the data and pager keys as specified in the docs.
I'm certain my access token is valid and my page ID are correct.
I've also tried to get the page_fans metric from the page insights via the following URL, but it simply returns an empty data object.
https://graph.facebook.com/v2.10/<page-id>/insights/page_fans?access_token=<access-token>
Is there another way to go about retrieving the like count for a page or any particular reason that the requests would succeed, but be missing the relevant data?
Facebook Doc Links:
https://developers.facebook.com/docs/graph-api/reference/v2.10/object/likes
https://developers.facebook.com/docs/graph-api/reference/v2.8/insights
UPDATE
I was able to retrieve the count by using this Graph API call:
https://graph.facebook.com/v2.10/<page-id>?access_token=<access-token>&fields=engagement
As New Hand pointed out, you can get the key directly, without going through the engagement field using the following:
https://graph.facebook.com/v2.10/<page-id>?access_token=<access-token>&fields=fan_count
Do you mean to get the fan_count?
Please try this:
https://graph.facebook.com/v2.10/<page-id>?access_token=<access-token>&fields=fan_count
Related
I'm trying to retrieve all the playlists from my account via
http://api.soundcloud.com/users/145295911/playlists?client_id=xxxxxx, as the API reference shows.
However, I can only retrieve recent 50 playlists instead of all of my playlists. I've been looking for this but it seems like no one has had this issue before. Is there a way to get all of them?
Check out the section of their API on pagination.
Most results from our API are returned as a collection. The number of items in the collection returned is limited to 50 by default with a maximum value of 200. Most endpoints support a linked_partitioning parameter that will allow you to page through collections. When this parameter is passed, the response will contain a next_href property if there are additional results. To fetch the next page of results, simply follow that URI. If the response does not contain a next_href property, you have reached the end of the results.
I'm getting all posts from a feed by using
GET https://graph.facebook.com/v2.11/<user-id>/feed?fields=id,admin_creator,...,from
and all works well. But the from-field in a post is a profile and the data returned does not tell me if the profile is of the type user, page etc. Is there a way to get that information? I had a look at this stackoverflow-post and it says I can use parameter metadata=1 to get the type, but how do I use it to get the type for each from-field in the collection returned?
No, adding metadata=1 is not the solution - that only lists what fields are available.
But you can for example ask for the fan_count field - only pages have a fan count, users don’t, so from whether that sub-field will be present, you can determine whether you are dealing with a page or a user. (Keep in mind that the fan count might be 0, so a simple if(fan_count) won’t do here.)
Syntax would be ?fields=from{fan_count}
I need to define a REST API which is supposed to take the object's unique identifier and return back the content. The content is retrieved from the database and is of JSON type.
So, I have a REST URL like this -
GET /data/{typename}/{objectid}
This would return the entire object content.
However, the content of the object could be large in size and so caller may like to specify only some or few of the properties to be sent as a response.
The natural thought that comes to me is to add a BODY to the GET API where user could specify the list of property names on that object to be retrieved.
But on doing some further research, it appears that a GET API with BODY is not recommended.
The other option that I can think of is to pass the property names in query string -
GET /data/{typename}/{objectid}?property=prop1&property=prop2...
But the list could easily become large.
Any suggestion on how should my API look like? Do I have to use POST?
Technically, using POST will work but is not preferred. If you are reading, use GET. Facebook, for example, has a similar use case where the /me endpoint has many filters, and the call is GET.
The final URL would be,
/me?fields=id,name,about,age_range,devices,currency,education
You can try it yourself from here,
https://developers.facebook.com/tools/explorer/145634995501895/?method=GET&path=me%3Ffields%3Did%2Cname%2Cabout%2Cage_range%2Cdevices%2Ccurrency%2Ceducation&version=v2.8
I recommend reading more about GraphAPI https://developers.facebook.com/docs/graph-api/overview/ and GraphQL https://graphql.org/
I would recommend using POST, because GET has a length limit.
What is the maximum length of a URL in different browsers?
otherwise you could make your query string look like this (for array)
so close :)
GET /data/{typename}/{objectid}?property[]=prop1&property[]=prop2...
When I use /{page_id}/feed?access_token=xxxx, this give me all the posts on the page, both by user and page. I want to limit and control the posts. I want to put constraints like:
Timestamp (that is to get posts after a particular timestamp)
Post id (to get post after a particular post)
Since getting all the posts from feed is irrelevant and in-effective. Is there any way to accomplish this ?
You can use
GET /{page_id}/feed?limit={nr_of_posts_to_return}&since={timestamp}
to be able to limit the number of results and specify the starting timestamp. Have a look at the reference here:
https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging
For your second Use Case you'd need to use the Batch API imho, because with a single Graph API request you can't filter on specific Posts. Instead, you need to use the Batch API to split this in two queries as described here:
https://developers.facebook.com/docs/graph-api/making-multiple-requests/#operations
The request would then look like this:
curl \
-F 'access_token={your_access_token}' \
-F 'batch=[{ "method":"GET","name":"get-post","relative_url":"{your_post_id}?fields=created_time"},{"method":"GET","relative_url":"{your_page_id}/feed?since={result=get-post:$.created_time}&limit={nr_of_posts_to_return}"}]' \
https://graph.facebook.com/
In Graph Explorer, you have to change the HTTP method to Post, then add a new field called batch. Leave the URL blank so far. Paste this as batch value:
[{ "method":"GET","name":"get-post","relative_url":"293088074081904_400071946716849?fields=created_time"},{"method":"GET","relative_url":"293088074081904/feed?since={result=get-post:$.created_time}&limit=1"}]
This works at least for me.
For others looking for a solution, it appears the 'since' done at the 'comment' and 'reply' levels are ignored. Which means this is not a solution for me.
The query Tobi provided will provide all the posts after the first 'since' but every comment and reply in those posts, regardless of that you set their 'since' to.
Further to this, if you wish to search for new comments , regardless of the age of the post, this fails as well. For example:remove the first 'since' and change to limit=1000 and only request comments as a fields using 'since' , this will return the last 1000 posts and all comments for all of those 1000.
That said, thank you Tobi for your time and showing me how to get everything I need in a single function call. I may experiment parsing the complete recordset every time. ( maybe too much traffic though!)
So I've been reading a lot on RESTfull design - specifically dealing with resources.
Taking the canonical example of Users, Posts, and Comments, with relationships as:
Users ---(hasMany)---> Post ---(hasMany)---> Comment
One may initially think to expose something like:
GET /users GET /posts GET /comments
POST /users POST /posts POST /comments
GET /users/id GET /posts/id GET /comments/id
PUT /users/id PUT /posts/id PUT /comments/id
DELETE /users/id DELETE /posts/id DELETE /comments/id
But then, say I want all Comments of a certain Post made by a particular User. I'd need to do something like:
GET /users/id
> someUser
> var postIds = someUser.posts()
GET /posts?id=<postIds[0]>&id=<postIds[1]>&...
> somePosts
> **application user inspects posts to see which one they care about**
> var postOfInterest = somePosts[x];
> var postId = postOfInterest.id;
GET /comments?id=postId
> someComments (finally)
Suppose though I only care about a Post or Comment in the context of it's owner. Suppose a different resource structuring which may (or may not?) be more natural:
GET /users
POST /users
GET /users/id
PUT /users/id
DELETE /users/id
GET /users/id/posts
POST /users/id/posts
GET /users/id/posts/id
PUT /users/id/posts/id
DELETE /users/id/posts/id
GET /users/id/posts/id/comments
POST /users/id/posts/id/comments
GET /users/id/posts/id/comments/id
GET /users/id/posts/id/comments/id
GET /users/id/posts/id/comments/id
Which to me, is probably a better representation of what the resources are. Then all I need is:
GET /users/id/posts
> somePosts
> **application user inspects posts to see which one they care about**
> var postOfInterest = somePosts[x];
> var postId = postOfInterest.id;
GET /users/id/posts/postId/comments
> someComments
This just seems more like navigating a file system than the previous method - but I don't know if its RESTfull at all (perhaps this is what REST was trying to get rid of) because in order to access a Comments resource, I need to know which User and which Post it belongs to. But the former requires 3 requests, while the latter requires just 2.
Thoughts?
Quite a bit of what is good REST is opinion but I would say your second approach is generally more "RESTful".
Basically you do want hierarchy in REST API and filesystem like navigation instead of query parameters. This is especially so if you follow HATEOS like API as someone can navigate your API.
In your second example it's important to have both GET /users/id and GET /users/id/posts so that when a request for the user's info is made it doesn't include all it's posts (or their IDs) too. And the second request will return their posts too. Often users have thousands of posts in a forum.
The disadvantage is that the api user always has to know the author of the post for which it wants to get comments. He'd essentially make a "give me that user and give me his/hers posts" request to your server which means that your server will make a query for that user and then select his posts. Instead it's much more convenient for both your user and your server to have separate requests - "give me that user", "give me that post" and "give me that comment". This means that you have to store separately users, posts and comments and for each post/comment store the id of it's author so that you can make selection of posts/comments by their author ("give me posts by this user", or simply "give me this post")
I would personally go with this variant of requests
GET user
GET post
GET comment
...
For every request I'd implement a where clause which will give the user of my api more options to make a specific selection. For example GET posts where userId='myID'. It can be implemented with url query parameters like http://myapi.mydomain.com/post?userId=user1 or inside the header. It will return a list of posts for that user. You can also have where clause for the post's ID - http://myapi.mydomain.com/post?id=123 which will return only this post. Note that for the first case - when you fetch a list of posts - you can only return some kind of short info for the posts (like id, author, summary...) and require an additional request to post?id=id for the full post content.
Having this implementation would give you at least two advantages:
the user of the api needs to know only one id to get some info - postID to get a post's content/comments, userId to get all posts/comments for that user
the selection is done on the server so less data is transfered over the network meaning faster responses (and potentially less costs for final users if they are on a mobile plan or something)
In my opinion this implementation giveс you loosely coupled objects (user, post, comment) and more flexible queries