If you want to retrieve public data from Facebook (typically a Page) you nowadays will have to use Facebook Graph API and thus provide an access-token. In the old days you could use some of the available feeds (following the RSS-principles) but that was back then.
I’ve seen some strange hacks around, but it’s quite simple to pull public data with a non-expiring access-token. (Impatient ones go here!)
The idea behind access-tokens is that the system you’re communicating with ‘knows something about somebody’; is that somebody a valid logged-in user, what is that user allowed to do, etc. For every request your application makes, on behalf of that user, you pass that access-token to the system.
Access tokens typically expire; to reduce the chance of getting in the wrong hands (Facebook offers appsecret_proof to prevent hijacking). When the user uses the application access-tokens get renewed in the background, when the user doesn’t use the application before the access-token expires, a new login / authorization action will provide a new one.
Facebook Graph API knows short- and long-term access-tokens, where the short-term tokens are used by the application’s client and the long-termed by the application’s server (using an app-secret).
The access-tokens mentioned above are “user access-tokens”. If you just want to pull out some public data, having users logging in and expiring access tokens is probably not what you want. But you can also in make requests to Facebook’s API on behalf of an a Facebook App, in stead of a user, working with an “app access-token”.
When you create an app at Facebook for developers, you have an app-id and an app-secret. In stead of requesting “oauth” for an app access-token, you can construct one yourself by combining your app-id and app-secret, when requesting from a server (not client!!), like this:
Note: using “appsecret_proof” doesn’t make much sense here
Here’s the method I used at the webserver (in PHP) to make calls to Facebook Graph API
For the ones interested in how you easily can work with the requested Facebook data in Ember, stay tuned and I’ll provide a snippet for your serializer.
Of course we’re using Ember Data to handle all this. First of all, model your data by adding a new model. You will at least have to define those attributes corresponding the fields-parameter from your API request.
For example ‘message’,’created_time’. Now setup your adapter, connecting to your ‘proxied webservice’.
When the data comes back to your client and back to Ember, Facebook has a slight different JSON-format than Ember expects, so we have to serialize it a little.
And what Ember expects depends whether you’re using the ‘old’ or ‘new’ adapter for handling JSON.
The previous de facto standard was the Ember Data RESTAdapter, the current de facto standard is the Ember Data v2 JSONAPIAdapter. What do they expect:
Ember Data RESTSerializer (using the extractArray method)
Ember Data JSONAPISerializer (using the normalizeArrayResponse method)
This is the model I’m using
The fields comment_count, like_count and share_count do not exist in the response from Facebook, they’re nested in ‘comments’, ‘likes’ and ‘shares’ objects. With the serializer’s normalize method you can make the response-data fit into your model.
Another thing I did here is adjusting the date-format given by Facebook, as Moment.js by default will fail with that input on Safari and IE, when there’s no colon in the time-zone.
Add this method to your serializer (either RESTSerializer or JSONAPISerializer) to get the model straight: