access_token, apis, applications, Authentication, connections, events, facebook, forums, graph_api, json, like_button, mosolo, oauth, one_true_web_path, open_graph, pages, people, permission, photos, photo_albums, platform, plugins, properties, query, Recommended, relationships, rest, search, Site Stuff, social, social_graph
The Facebook APIs, part 4: Getting the good stuff via the Graph API
This is my final installment in a four part series on Facebook’s MoSoLo related APIs and technologies. You can read the previous three posts here: Part 1 provided a brief history of the Facebook Platform, part 2 introduced social plugins including the ever present Like button, and part 3 delved into how to use Facebook’s implementation of the Open Graph protocol to enable your content for Facebook’s users.
I’ve saved the best part of the Facebook Platform for last: The Graph API. As Facebook describes it:
The Graph API presents a simple, consistent view of the Facebook social graph, uniformly representing objects in the graph (e.g., people, photos, events, and pages) and the connections between them (e.g., friend relationships, shared content, and photo tags).
You interact with the Graph API by requesting information on the current state of the object(s) of interest in the graph. Like all good One True Web Path RESTful web APIs, Graph API requests result in JSON server responses that are manipulable in client-side JavaScript or your own language or tool of choice.
To access the public properties of an object in the graph, you make a secure HTTP request to graph.facebook.com
with a path of /ID
where ‘ID
‘ is the unique ID of the object of interest within the Facebook social graph.
For instance, to request the public properties of the object representing my Facebook account, you would make this call:
https://graph.facebook.com/753868366
To see the graph in action, click the above link. You should receive the following JSON server response:
{ "id": "753868366", "name": "Bill Day", "first_name": "Bill", "last_name": "Day", "link": "http://www.facebook.com/billdaycom", "gender": "male", "locale": "en_US" }
Note that for people and pages with Facebook usernames, you can use a username in place of an ID in graph API calls. So you can alternatively request the properties of my account by making the call shown in the first part of this series, https://graph.facebook.com/billdaycom, which will return the same JSON object as above.
The Facebook Platform developer site has a username of ‘platform’, so you can request information on it within the graph via:
https://graph.facebook.com/platform
which returns:
{ "id": "19292868552", "name": "Facebook Platform", "picture": "http://profile.ak.fbcdn.net/hprofile-ak-snc4/hs451.snc4/50414_19292868552_7650_s.jpg", "link": "http://www.facebook.com/platform", "category": "Product/service", "website": "http://developers.facebook.com", "username": "platform", "founded": "May 2007", "company_overview": "Facebook Platform enables anyone to build social applications on Facebook and the web.", "mission": "To make the web more open and social.", "likes": 1379443 }
All objects in the graph may have a picture that represents them. For a person, this picture is their profile photo, but other things such as events, pages, applications, and photo albums all have such a picture, too. To render that picture, you send a request of the format /ID/picture
; for example, my current picture (profile photo) is available via:
https://graph.facebook.com/billdaycom/picture
which renders as:
You can also request the picture in other sizes, for example get the large size via:
http://graph.facebook.com/billdaycom/picture?type=large
which renders:
The Graph API would be minimally useful if these were the only sorts of operations it provided. It starts getting really interesting when you learn how to ask the system for more information than you initially have.
From → Uncategorized
Comments are closed.