If you want to build applications that work with Facebook’s Graph data then you need to understand the Graph API. Thankfully, the Facebook Social Graph format is built to be as transparent and straightforward as possible.

Everything on Facebook has a Facebook Graph ID: users, pages, events, groups, pictures… Learning to navigate the interconnections between these objects is the first step towards using the Facebook Social Graph to build Facebook native application.

Most of these relationships are has-a type relationships: a user has a profile picture, an album has a picture in it, a picture has a user in it. But as you can see these relationships can quickly become recursive – I have a picture, the picture has me tagged in it. Keeping these relationships straight is the first challenge and in order to do that it helps to think about “roles.”

The objects in the Facebook Social Graph framework don’t expose the semantics of different roles directly, because each object type may play many different roles. For example: when a user is related to an event they may play several roles. The event has zero or more attendees; the event has zero or more invitees, the event has an organiser. These are different relations and, while all of them are types of user object, the way they are exposed in the Facebook Social Graph differs greatly. To understand how to find different objects playing different roles, you need to understand the semantics of “connections.”

Put succinctly – the Facebook Social Graph has two types of entities: “objects” and “connections.” These approximate to entity types and relations but there are some subtle differences that we won’t go into here.

All Graph Data is returned in JSON format, and all queries are passed as URLs. Let’s break a query down:

The first part of the URL takes you to the Graph API. The part after .com/ is the object id (it might be a username, a Facebook Social Graph ID, a pagename, or a recognised Facebook constant such as “me” – which always refers to the logged-in user.)

The next argument – in this example it is “likes” – determines the kind of connections we are interested in. These include: friends, likes, tags, events, notes and so on.

It’s important to note that events, groups and notes are “overloaded” terms – as these are both types of object and types of connection.

The generic, structure, then, of a Graph API query is:

https://graph.facebook.com/OBJECT_ID/CONNECTION_TYPE

The final part of the query is the access token. This is obtained from the user by asking for their permission to access parts of their profile using the OAuth 2.0 framework. Once the user has logged in and granted your application authorization to access their data, you will be granted an access token that is appended to the query string.

Imagine we want to discover the information that Facebook has about the user Brett Taylor, and we know that his user ID is btaylor. The query

If you want to explore the Graph API, the best place to start is Facebook’s own API Explorer widget. It will allow you to generate access tokens to expose data in the graph. With the explorer you can view the types of data fields that are available for each object and the types of connections that can be explored. Understanding the Graph API is the first step towards building Facebook