There’s a bit of confusion concerning the base64 decoding of the signed request returned by Facebook. Their FAQ mentions you have to use base64 decoding for URLs specifically which handle the proper character substitution for URLs.
The other error has to do with the end padding that is omitted. If you do a simple JSON parse on these base64 encoded string without padding, you may end up finding yourself missing a “}” on the end.
For instructions on getting the proper JSON, see this.
I took a look at Facebook Graph API because I wanted to incorporate the ability to search nearby places into my mobile application. Currently, I’m using SimpleGeo to accomplish this which has been nice.
But, what can I say? When I heard the word “free” and considering I’m already working on other Facebook integration I thought it was worth looking into.
It reminds me of a conversation I had with a Facebook product person. A few months ago he asked me how companies like SimpleGeo could survive given FB could just create their own Places API (this was before any announcement of an open API but after they introduced Check-Ins). I should’ve taken this as foreshadowing.
I replied that SimpleGeo offered some interesting and different channels for making money like their layers service which is a marketplace for people to buy and sell data. I think the obvious question about their query API was that they couldn’t really compete if Facebook wanted to go in this direction.
Lo and behold Facebook announces their Places API. Shocked, I was.. but maybe I shouldn’t have been. It was like a page out of Internet Explorers book (~1996). Have a competitor (Netscape)? Just make your product free!
However, in these situations, the devil is always in the (developers) details. After looking deeper into the API, it appears that any requests to the Graph API requires a user authorized access token. In other words, an authorized FB user is needed before one can query nearby places.
When one considers why it was done this way, it brings about some possible intentions by Facebook. By designing it this way, they are saying ONLY Facebook authenticated users can query it. So, while my application supports optional Facebook integration, only those users would have access to it. It’s written more as a feature for a Facebook user than it is as an infrastructure service like SimpleGeo.
I’m hoping I’m wrong and someone will point out a capability to query the Places API just using my API key. I have a feeling this isn’t the case. I’m not an expert, but by design the Graph API seems to be architected around authenticated users. In some ways this scares me. I’ve never been one to promote any FUD around Facebook domination but this is a step in that direction.
Coming full circle, this is how paid products like SimpleGeo will not just survive but likely thrive against free products. Developers aren’t tied to any one service to get their reverse geo-location capabilities. In general, this tends to be true of the APIs that are trying to protect their dominance in their respective: There will be restrictions on the use of their service that can handicap your application. Whereas when you come across an independent service that has no interests to protect, you may have to pay some money but you’ll get a more flexible service that can serve your needs. Case in point: Google App Engine vs Amazon AWS.
