One thing that sets Facebook apart from its competition in the social networking arena is its extensive use of building the site’s platform, features and applications with open-source software. Taking the open-source philosophy to heart, Facebook shares a set of Application Programming Interfaces (APIs) that developers can use to tap into the social network and that extend the developer’s Web applications and sites. The main Application Programming Interfaces offered by Facebook include the Ads API, Credits API, Chat API and Graph API.
The most widely used Facebook API is the Graph API, which is a core feature that charts the social graph for all connections between people, pages, events, posts, photos, comments and “likes.” Tapping into the Facebook social graph lets your Web applications interact with the data in multiple ways. You can return a user’s most recent posts, access and download an entire photo album and discover the most popular “likes” across the entire social network. The Graph API includes a search feature that lets you easily retrieve and parse this data, as long as the user’s data is public and not private. If it is private, then your application will need a Facebook access token to get permission from the user.
The Chat API lets a programmer integrate the Facebook Chat feature directly in a Web-based or desktop application. Instant messaging among Facebook friends is possible with the Jabber service and XMPP protocol. The Chat API lets users to send and receive plain-text messages, but not HTML-based ones. Additionally, the API lets developers retrieve a user’s photo via the vCard or XMPP protocols; once it’s retrieved, the photo can be displayed as the chatter’s profile picture.
Facebook Credits are the platform’s internal payment system to purchase in-app items, services and more. Basically, a credit gives a user the ability to buy virtual goods within a Facebook app. An app developer can place a “Pay with Facebook” button in her game, encouraging users to purchase her digital goods. The Credits API encompasses two components — the front-end and back-end credits system. The front end handles everything Facebook users see, while the back-end API is used to manage credits received and post status updates on behalf of the user.
The Ads API gives developers and high-end advertisers the ability to create their own applications to address their advertising needs and concerns. The API is available as an alternative to using the default Facebook Advertising Manager Tool, which is free to use when creating and managing your ads. To use the Ads API, a person or business must agree to the terms and conditions so the user is placed on the API whitelist. Otherwise, a developer or vendor won’t be able to access the application interface.
Facebook uses OAuth2 as their API protocol, which stands for Open Authorization. The developer Eran Hammer-Lahav likes to compare it to a valet key. This protocol allows the user to share some information with your application, such as contacts, photos and videos with a token, but doesn’t give username and password. OAuth began in November of 2006. The new version OAuth2 is not backwardly compatible with OAuth.
The user authorization is addressed by the OAuth Dialog. The first step is determining if the user is logged into Facebook by validating the login cookie that is stored on the user’s browser. If the user is not logged in, they will be required to enter their email and password.
The next step is authorizing the application. The system is set up to access basic information. This information includes: name, profile picture, gender, networks, user ID, list of friend and any other information that is shared with anyone. However, if you need more information than this, you must request specific permissions by adding a scope parameter. You can find all of the permissions that are available in the permission references. Facebook warns that there is a strong negative correlation between the number of permissions requested and the users that grant them. They recommend only requesting the needed permissions.
If the user selects “allow” on the permissions, the application is authorized and an authorization code is returned. You must also obtain an app secret from the Developer’s App. Then you pass both the authorization code and your app secret to the Graph API token endpoint. If the application is authenticated and the user is authorized, you get a HTTP302 and the location of the URL returned. If there is a problem, you get a HTTP 400 and an error message.