Documentation: https://developers.facebook.com/docs/achievements/
Each achievement must possess a unique URL with the appropriate Open Graph protocol <meta> tags. We will scrape the achievement’s unique URL and use the information provided in the tags to generate the Ticker stories. The Ticker stories will redirect to the achievement’s unique URL.
So each achievement simply needs an HTML file that has nothing but meta tags in it? That seems weird to me so I just want to confirm. Since you still have to "create" the achievement via an API call (different than awarding it to a user), I don't understand why that doesn't suffice.
What's your question? If it's 'do i definitely need a page with the meta tags for Facebook's crawler?' the answer is 'Yes'
You can generate the tags programmatically via URL parameters, and can redirect any non-Facebook-crawler users that hit those URLs somewhere else if you want
Related
I would like to achieve the following:
GET all posts from a page and their related content (attachments, likes, visibility, tags, shares, comments, creation time...)
POST all that content in a new page
Assuming that I am admin of both pages.
I know that it's pretty straight forward to loop over the feed of a page and get all the posts' information. However, I'm not so sure about the POST part:
I guess that Facebook doesn't allow to "clone" people's
like/shares/comments below each post, on their behalf?
Considering that I will delete the first page, will all attachments disappear from Facebook's servers as well?
You cannot post in behalf of another user. And you cannot get all information you need with the Graph API.
What about renaming the page? If you like to delete the first page and clone it before, it looks like a rebranding or something ...
I was reading over the changes to the Facebook Like button that are scheduled to take place in November 2012, and I'm a bit confused (and hoping someone has an answer).
I understand that the REST endpoints are being removed in favour of regular pages, but here's where I'm confused.
Previously, if I did the following...
Create a page
Add the correct OpenGraph metatags to the page
'Like' the page
... Then an OpenGraph object would be created automatically (and could be verified by visiting http://graph.facebook.com/?id=my_url). If I published to that OpenGraph object, people would receive updates.
However, with the changes, if I understand them correctly, the OpenGraph object is no longer created? Or it is created, but I still need to create a Facebook page to administer and send messages?
Any help would be appreciated.
However, with the changes, if I understand them correctly, the OpenGraph object is no longer created?
That phrasing is a little besides the point.
You create the Open Graph object, by setting up a page with appropriate OG meta tags.
And Facebook will count likes for this URL, like for every other URL.
Or it is created, but I still need to create a Facebook page to administer and send messages?
No admin pages will be created automatically any more; although you can convert existing ones to normal public Facebook pages. But then you have to point the like button to the URL of that new Facebook page instead of your OG URL to be able to publish updates to your fans. (So this will behave basically like a normal Facebook page that was set up to be one in the first place; only this step allows you to “migrate” your existing likers for your OG URL to that page, so you don’t need to have a “fresh start” with your Facebook page.)
The document further describes, what to do if you still need the ability to publish updates to the users liking your OG URL – by providing fb:app_id and fb:admins meta tags:
“This will ensure that the Like Button admin link still appears on the given Open Graph page. The admin page for a given Like Button is also accessible to administrators from https://www.facebook.com/bookmarks/pages”
But publishing updates this way will only work until the Like Button admin page is fully deprecated. From then on, you will have to use a Facebook page, if you want to be able to publish updates to the users who liked your page.
For the past few months I've been using the "link" field present in data returned for a Like in order to determine whether the Open Graph object being liked is part of my application. For all that time the link field contained the og:url value for the object being liked. Now the link field contains a URL for a Facebook page that is automatically created for the object being liked. I've found that sometimes the "website" field contains the og:url value for the object but sometimes the website field is not returned (even when explicitly requested).
Is anyone else experiencing this issue? Did I miss an announcement from Facebook about how they are completely changing the meaning of these fields? Am I taking crazy pills? Is this just a symptom of the many current bugs surrounding like/send functionality right now? I wanted to throw this out to the community before filing a bug report.
Open Graph Protocol
Page Administration
To administer your page, you need to associate it with either your Facebook account or your Facebook Platform application. It is valid to associate your page with both user accounts and a Facebook Platform Application.
To associate the page with your Facebook account, add the additional property fb:admins to your page with a comma-separated list of the user IDs or usernames of the Facebook accounts who own the page, e.g.:
<meta property="fb:admins" content="USER_ID1,USER_ID2"/>
Each listed user must click Like on the URL to be approved as an admin. This is to prevent users being made admins without their consent.
So I think using the site url depends on the admin users liked the page or not.
I have perused the questions asked about this, but I still don't have a definitive answer.
I have an application and would like to build a RESTful API to expose a subset of information. I have three resources:
users
reports
photos
Users have reports and reports have photos. Photos cannot exist outside of reports and reports cannot exist outside of users.
I have designed the following URLs for my requirements
User login, server responds with token which is sent in the header of all API calls
GET example.com/api/
Get user info
GET example.com/api/users/{username}
Get all user reports
GET example.com/api/users/{username}/reports
Get all photos of a report
GET example.com/api/users/{username}/reports/{report_id}/photos
Add a photo
POST example.com/api/users/{username}/reports/{report_id}/photos
Delete a photo
DELETE example.com/api/users/{username}/reports/{report_id}/photos/{photo_id}
Modify photo description
PUT example.com/api/users/{username}/reports/{report_id}/photos/{photo_id}
Questions
Is it good practice to add a resource id in the URL, i.e. resource/id, or should this rather be added as a query parameter?
Is this method of chaining resources, i.e. resource/id/sub-resource/id/etc., acceptable and good or should I put all my resources at the top level and specify its position with query parameters?
Nothing wrong in this design.But this creates long URL which sometime are difficult to understand and the user of the API needs to know the hierarchy.Moreover the consumer of the API need to write more code in little bit non-standard way(Even though it can be done, but will be little messy). Think this from a different perspective
You have three resources and each has its own identity.So if we refactor the above URI's it will looks like below (I am demonstrating only GET)
User Resource:
Get users list
GET example.com/api/users
Get specific user
GET example.com/api/users/{username}
Report Resource:
Get all reports
GET example.com/api/reports
Get a specific report
GET example.com/api/reports/{report_id}
Photo Resources
All Photos
GET example.com/api/photos
Specific Photo
GET example.com/api/photos/{photo_id}
User All Reports
GET example.com/api/reports?username={userName}
Specific report of a user
GET example.com/api/report?username={userName}&report_id={reportId}
User All Photos
GET example.com/api/photos?username={userName}
User All Photos for a report id (You may not need user Name if report_id is unique irrespective of the user, which will further simplify the URI)
GET example.com/api/photos?username={userName}&report_id={reportId}
All photos of a report
GET example.com/api/photos?report_id={reportId}
This simplifies the understanding and more standard code can be written on the consumer side using this approach.
IMHO you are modelling it well.
Regarding 1 I'd rather go with resource/id rather than query param. But one thing you must have in mind when modelling is the cache mechanism by proxy and so on. So do not forget the headers.
I go for query params for filtering and those sorts.
About the login, the credentials should be in the headers, and no specific resource is needed. Just apply per resource security.
I don't see anything wrong with your scheme.
Most frameworks nowadays use a similar standard for specifying url's (like Django).
In my personal opinion, it makes the URL more readable and a bit nicer for the user.
I would like to be able to show short news messages to users of my app. I am thinking the nicest way to do this would be to add a hashtag (like #appnews) to my Twitter updates that I want shown in-app; my app will make this happen by scanning my Twitter stream at startup and surfacing updates with that hashtag. This seems super-simple, and I'd like to know if there's some way to do this via built-in (HTTP?) calls to my Twitter page, rather than incorporating a whole framework like MGTwitterEngine. The user will not be logging in or posting Twitter updates at any point.
Thanks!
You can retrieve any user's public tweets in XML format by retrieving the following URL:
http://api.twitter.com/1/statuses/user_timeline.xml?screen_name=DWRoelands
(This example will display my tweets). Once you've got the list of tweets, you can parse through the XML document in whatever way is easiest for you.
Rather than tagging posts with a hash tag, I would recommend simply starting a new Twitter account that is solely for the news items you described.