I've been programming a lot with restfb, but I'm not able to do a counting of comments, only the comments without the answers, the image can better illustrate.enter image description here
Example post comment facebook
My code
Post post = clienteFacebook.fetchObject(idPostagem,
Post.class,
Parameter.with("fields", "comments.limit(0).summary(true)"),
Parameter.with("filter", "toplevel"));
System.out.println("Comments count: " + post.getCommentsCount());
Out code comments count
But I need to get only actual comments from the publication, in this example 57 comments.
In https://developers.facebook.com/docs/graph-api/reference/v3.2/object/comments I have some references of filter - toplevel but without success.
I also tested with Comment instead of Post but without success.
How can I get 57 posts in a post?
Please try the following code:
Post post = clienteFacebook.fetchObject(idPostagem,
Post.class,Parameter.with("fields", "comments.limit(0).summary(1).filter(toplevel)"));
System.out.println("Comments count: " + post.getCommentsCount());
As you can see the filter is part of the fields parameter. But the strange thing is, toplevel is the default filter if no filter is provided. So maybe it is something different.
Maybe you can get in touch with us (RestFB Team) directly, so we can help a bit more in depth ;)
Related
I always have the doubt that you can see below when i need to create theresource URLs for a REST API. I wonder if some one can help me.
Let's suppose that i have two models.
User
Post
User can submit his own posts and can comment his own and another posts.
Main resources URLs for User would be:
GET /users # Retrieve all users.
POST /users # Create a new user.
GET/DELETE/PUT /users/{user_id} # Get, remove and update an user.
Main resource URLs for Post would be:
GET /posts # Retrieve all posts.
POST /posts # Create a new post.
GET/DELETE/PUT /posts/{post_id} # Get, remove and update a post.
My problem come when for example i want:
Top 10 submitters (filter for a parameter(external link, discussion, all)). The URL should be:
GET /users/top?type=ext
GET /users/top?type=disc
GET /users/top # for all
Or maybe it should be:
GET /users?top=ext
GET /users?top=disc
GET /users?top=all
The same but with posts:
Top 10 commented post (filter for a parameter(external link, discussion, all)). The URL should be:
GET /posts/comments?type=ext
GET /posts/comments?type=disc
GET /posts/comments # for all
Or maybe it should be:
GET /posts?top=ext
GET /posts?top=disc
GET /posts?top=all
Any of above options are good for you or it should be another way?
Regards
I like to think of the REST URI as a model representation in itself.
So /users/top doesn't make a lot of sense but /posts/comments seems to be fine (as comments could also be a different model). But for your case, I recommend other set of query parameters as they're widely used for filtering & sorting requests. So in your case, I'd recommend something like:
GET /users?sort=ext&order=desc&limit=10
which would help me understand that I'm requesting 10 user resources which have been sorted for ext in the descending order. (you can even change it to type=ext if you want)
As usual; REST doesn't care what spellings you use.
One place you might look for inspiration is... stack overflow itself. Do these URI look familiar?
/questions?sort=newest
/questions?sort=featured
/questions?sort=votes
The API has pretty decent documentation, which will also offer hints at decent spellings to deal with paging and search ranges.
That said, IMDB takes a different approach - The Shawshank Redemption uses a straight forward "I am an element of a collection" spelling
http://www.imdb.com/title/tt0111161/
But the top rated titles of all time? they appear as a chart
http://www.imdb.com/chart/top
But i want to know if there is a standard according to #Hawkes answer or there is no standard at all.
No standard at all; just local spelling conventions. Which is, to some degree, part of the point of REST: the server can use whatever spellings for URI make sense, and the client just "follows its nose" based on its understanding of the processing rules for the media type and the data provided by the server.
i have been trying to get few information details that somehow always return as null. the one that is most needed for me is likes count (or even better, just all the likes. i want to know who liked the post).
my code is
FacebookClient fc = ~my facebook client in version 2.3~;
Post post = fc.fetchObject(anID, Post.class ;
System.out.println("Likes Count - "+ post.getLikes().getData().size());
im trying like so cause this way i get the number 25. so i got it , its limited to 25. how do i get all of the likes??
by the way , if ill just try post.getLikesCount() ill get nothing.
if anyone knows how to handle this situation he might also know how to get Attribution , Shares and FeedTargeting.
thanks for you attention!
To get all Likes of a Post you can request the <postid>/likes endpoint. You can iterate over the pages and the likes.
Perhaps there's a way to use the field expansion, but I'm not sure atm.
Hello Graph API experts,
When you call /[post_id , the result contains "comments" field which has "count" field that is supposed to have the total number of comments for this particular post.
Now, if you call /[post_id]/comments , you get the actual comment data, one by one.
The problem I am facing is that, when I compare the "comments.count" field's value and the number of all of the actual comment data returned, they are different.
What's even worse, if you then look at the same post on Facebook.com's Timeline where you can see the number of comments for that post (i.e. "view all * comments" link), this number is also different from the "comments.count" field value.
And this is not only happening to one post, but to many of them - I observe this tend to happen more to posts with more than 100 comments (I actually counted all the comments on Timeline, and it matched the number of the actual comment data returned from /[post_id]/comments API call).
Is this a normal API behaviour? Which number should I or would you trust if this is the way it is?
ok, when you looking some facebook comment counts on some timeline posts, you woulld see that count for ex. 16 comments, and when you try to count comments manually on the post you may see it's looking 15 comments, so where is it that missing comments ? is that a wrong count by facebook ? no not actually, it's because, some people changing profile privacies as like don't show my comments people who aren't my friends, or we haven't any mutual friends, etc. it's because you cannot get these privatized comments from graph api, but these comments aren't excluding in total count. So what's the solution, just be sure get all the data correctly what facebook provide you. And compare it, how many comments looking like missing, and show missing counts as private comments count in your application. I think is much better.
Welcome to the world of Facebook API programming. Yes, this is normal (but apparently not desired) API behavior. This is one of the inconsistencies we're faced with when programming around their API. CBroe is probably correct in his comment above, it is data inconsistencies between servers in their API cluster.
in addition to this there are problems with pagination, you can use the offset + limit parameters to say how much data you want and from where to take it, if you deal with number of posts, you can say offset=0 and limit=50 and it'll work, but then if you try offset=100 and limit=50 it might return empty data, but then try offset=100 and limit=100 and it'll return 100 posts.
the api is just buggy and full of inconsistencies which don't seem to have any way to solve them.
I think we got oversold on the opengraph, I don't think it's what facebook told us it would be and I'm starting to feel the burn from selling that to my boss and finding out that I perhaps can't deliver :(
I'm building an app which allows users to post articles to their facebook wall. When an article is posted, I retrieve the post id and store that in the database along with the rest of the article details. Now I want to be able to show the comments made on that post when someone views the article in my site; I would also like to allow users to add comments to the post from my site.
I know that the user is always logged into Facebook when they are viewing the article, as the system checks for that earlier on.
I've been using the PHP SDK, and thought all I had to do was something like:
$post_comments = $facebook->api('/' . $post_id . '/comments');
However, when I do this, I get the following error:
Fatal error: Uncaught GraphMethodException: Unsupported get request. thrown in /APP_PATH/facebook/src/facebook.php on line 560
I really don't have much of a clue what I'm doing here, to be honest, as I'm very new to the Facebook Graph API, and I can't seem to find a lot of documentation on it.
Can anyone tell me what I should be doing here, or point me to some documentation I could read about it?
Thanks!
It should work.
Here is the code I am using which is working for me.
$comments = $facebook->api($postid . '/comments');
Make sure your postid is a valid one.
Alternatively, you can directly type that url in browser to get details like this
https://graph.facebook.com/<postedid>/comments
Please refer this link for further reference
http://developers.facebook.com/docs/reference/api/Comment/
I don't know what your PHP library is doing, but you can actually access comments by reading graph.facebook.com/<post_id>/comments. Indeed, try with this one from the doc.
Are your sure of your post id? Try to call the buggy function with 19292868552_118464504835613 as post id. It has to work.
I'm doing research into a web API for my company, and it's starting to look like we might implement a RESTful one. I've read a couple of books about this now (O'Reilly's "RESTful web services" seeming the most useful) and have come up with the following set of URIs and operations for an object that can be commented on, tagged, and rated.
It doesn't really matter what the object is, as this scenario applies to many things on the net, but for the sake of argument lets say it's a movie.
Some of these seem to fit quite naturally, but others seem a bit forced (rating and tagging particularly) so does anybody have any suggestions about how these could be improved? I'll list them with the URI and then the supported verbs, and what I propose they would do.
/movies
GET = List movies
/movies/5
GET = Get movie 5
/movies/5/comments
GET = List comments on movie 5
POST = Create a new comment on movie 5
/movies/5/comments/8
GET = Get comment 8 on movie 5
POST = Reply to comment 8 on movie 5
PUT = Update comment 8 on movie 5
/movies/5/comments/8/flag
GET = Check whether the movies is flagged as inappropriate (404 if not)
PUT = Flag movie as inappropriate
/movies/5/rating
GET = Get the rating of the movie
POST = Add the user rating of the movie to the overall rating
Edit: My intention is that the movie object would contain its rating as a property, so I wouldn't really expect the GET method to be used here. The URI really exists so that the rating can be an individual resource that can be updated using the POST verb. I'm not sure if this is the best way of doing it, but I can't think of a better one
/movies/5/tags/tagname
GET = Check whether the movies is tagged with tagname (404 if not; but if it is tagged with the tag name should it return the actual tag resource by redirecting to something like /tags/tagname?)
PUT = Add tag tagname to the movie, creating the tag resource /tags/tagname if required
DELETE = Remove tag tagname from the movie, deleting the tag resource tags/tagname if nothing is tagged with it after this removal
Note that these wouldn't be the entire URIs, for example the URI to list the movies would support filtering, paging and sorting. For this I was planning on something like:
/movies/action;90s/rating,desc/20-40
Where:
action;90s is a semi-colon delimited set of filter criteria
rating,desc is the sort order and direction
20-40 is the range of item indices to get
Any comments about this API scheme too?
Edit #1
This post is getting quite long now! After reading some of the answers and comments, this is the changes from above I'm planning on making:
Tags will be handled as a group rather than individually, so they will be at:
/movies/5/tags
GET = List tags
POST = Union of specified tags and existing tags
PUT = Replace any current tags with specified tags
DELETE = Delete all tags
I'm still really not sure how to handle flagging a comment though. One option is that instead of POSTing to a comment replying to it, a comment object will include its parent so it can be POSTed to the general URI, i.e.
/movie/5/comment
POST = Create a new comment (which may be a reply to a comment)
I could then use the POST to a comment to flag it. But this still doesn't feel quite right.
/movie/5/comment/8
POST = Flag comment
Most of what you have looks good. There were just a couple of strange things I saw. When I put my URLs together, I try to follow these four principles.
Peel the onion
If you make the R in REST really be a resource then the resource URL should be able to be peeled back and still be meaningful. If it doesn't make sense you should rethink how to organize the resource. So in the case below, each makes sense. I am either looking at a specific item, or a collection of items.
/movies/horror/10/
/movies/horror/
/movies/
The following seems funny to me because flag isn't a resource, it's a property of the movie.
/movies/5/comments/8/flag -> Funny
/movies/5/comments/8/ -> Gives me all properties of comment including flag
Define the View
The last peice of the URL describes how to show the resource. The URL /movies/horror/ tells me I will have a collection of movies refined by horror. But there might be different ways I want to display that collection.
/movies/horror/simple
/movies/horror/expanded
The simple view might just be the title and an image. The expanded view would give a lot more information like description, synopsis, and ratings.
Helpers
After the resource has been limited and the proper view figured out, query string parameters are used to help the UI with the little stuff. The most common query string parameters I use are
p => Page
n => number of items to display
sortby => field to sort by
asc => sort ascending
So I could end up with a URL like
/movies/horror/default?p=12&n=50&sortby=name
This will give me the list of movies limited to horror movies with the default view; starting on page 12 with 50 movies per page where the movies are sorted by name.
Actions
The last thing needed are your action on the resource. The action are either collection based or item based.
/movies/horror/
GET -> Get resources as a list
POST -> Create, Update
/movies/horror/10/
GET -> Get resource as item
POST -> Update
I hope this helps.
I disagree with the edit. Queries should be defined by querystrings as per Martijn Laarman's post. i.e.:
/movies?genre=action&timeframe=90s&lbound=20&ubound=40&order=desc
Well, the way I see it some of the information you return now as objects could simply be added to the metadata of its parent object.
For instance, rating could be part of the response of /movies/5
<movie>
<title>..</title>
..
<rating url="movies/ratings/4">4</rating>
<tags>
<tag url="movies/tags/creative">creative</tag>
...
Removing a tag simply means posting the above response without that tag.
Also queries should go in URL variables, I believe:
/movies/?startsWith=Forrest%20G&orderBy=DateAdded
Based on my understanding of ROA (I'm only on chapter five of RESTful Web Services) it looks good to me.
This is an awesome initial draft for a spec of a REST API. The next step would to specify expected return codes (like you did with "404 No Tag Available"), acceptable Content-Types, and available content-types (e.g., HTML, JSON). Doing that should expose any additional chinks you'll need to hammer out.
#Nelson LaQuet:
Using the HTTP methods as they are actually defined gives you the safety of knowing that executing a GET on anything on a web site or service won't eat your data or otherwise mangle it. As an example (pointed out in RESTful Web Services) Google's Web Accelerator expects this behaviour -- as stated in the FAQ -- and presumably other services do too.
Also it gets you idempotency for free. That is doing a GET, DELETE, HEAD or PUT on a resource more than once is the same as doing it only once. Thus if your request fails then all you have to do is run it again.
This is not REST.
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven