Benefits to Proxying APIs Using with Your Own Servers

Last night I was hacking away at some new features in EraseUrX and I ran into, what I still don't know is, a coding error on my part or incomplete api with Facebook. At this point it really could be either one. I am using their graph api and have no problem authorizing a user, requesting extended permissions and getting a list of friends from that user.  However, when I try to post a message to someone else's wall I get an OAuthException message that Facebook couldn't authorize the application.  WTF?! I thought possibly that my access token was invalid or that my url that I was posting with was incorrect. Nope they are fine. I tested it using curl and the post went through just fine with the same access token. After a few more code changes to no avail I decided to approach it from a different angle.

Though most big services take a lot of pride and care in their API's that they produce they still inevitably change method names, authentication schemes, parameters, validation, etc. This type of uncertainty isn't easily managed when you have compiled code on a device.  If/when a service provide decides to change/delete something from their API, your app could possibly break leaving the users pissed and blaming you.  Even though it TECHNICALLY isn't your fault, developers should take ownership and responsibility to do whatever they can to provide applications with the best user experience.

I decided that I would create a small webapp/script on my server that would act as a proxy or broker between api calls from my app and Facebook. On the surface it looks like it is overkill, but the benefits definitely outweigh the overhead.

A standardized output
Depending on if my request is successful or not to Facebook I will get a different JSON response which is fine, but the JSON structure is also different.  If I were do to all response checking on the phone, not only is it EXTREMELY verbose, but I don't want to have to parse through two different object graphs.  Instead my webapp will get the respone(s) and create a standard response structure of my choice. Something like this:

// Success
{
  'status': 'success',
  "data": [
      {
         "name": "John Doe",
         "id": "55555"
      },
{
         "name": "Jane Doe",
         "id": "6666666"
      }
  ]
}

//Error
{
  'status': 'error',
  "data": [
      {
         "message": "Bad error message",
   "title" : "Bad error message  title",
         "type": "666"
      }
  ]
}

Having a standardized response my app code looks for an exact value in the json string, 'status', and transverse the rest of the json response and process everything accordingly.  Efficiency.

APIs Change
As stated above service providers (Facebook, Twitter, Google, etc.) can/will change their api at any given time.  It is by far easier to change code in a webapp, test and deploy then it is to modify code, no matter how well written it is, in a native device app.

Better Monitoring and Logging
Having your native apps hit your script will allow for better monitoring of a) how many user's are actually using your app b) if there are errors you can track down them down easier and faster c) more accurate analytics that are based on your use cases.  In addition, being able to integrate those stats into other business initatives and integration points.

Result Caching
I would bet that companies like Facebook are caching result sets for a better/faster response, but we will never know and to the full extent they are caching.  You can setup your own caching architecture that will best serve you and your apps needs supplementary to whatever may or may not be provided by the service.

Disaster Recovery
We have all seen the Twitter "fail whale" which means that ANY app trying to utilize that API is housed for x amount of time, which is not a good thing.  Having your own server side script would allow you to handle those unfortunate instances when the service is unavailable by using a cached copy of the result set if one is available or send back a message in your standard response that allows your app to present to the user that that piece of functionality isn't working at the moment.

By handling the majority of the requests/response on my server I reduce the amount of boilerplate code/frameworks that are in my iPhone/Android/Blackberry app, able to standarize the message format for more efficient parsing on the device and provide a better user experience.

Facebook Graph API with a Native iPhone Application

One of the biggest gripes that I have with working with the FBConnect iPhone SDK, and really the Facebook API, in general was having to deal with a very inefficient REST implementation.  Callback after callback, protocol after protocol, major bugs (that have yet to be fixed as far as I know), and my biggest issue is the nasty user experience having to login a user.  I was very excited to hear when last month Facebook announced they had came out with a new API that would allow great security, ease and flexibility.  The pains of having to go through currently working functionality and refactor the code to accommodate the new features wasn't too much of a problem for me because it would mean a reduced code set on my part and I would be able to get rid of the Facebook Connect SDK.  I set out to test my theories and functionality via a quick web app.  No problems.  Then I proceeded over to my native iPhone app.  EraseUrX v2.0.  The new authentication mechanism utilized in Open Graph is OAuth2.0.  While many of the headaches and complexities of using OAuth are addressed and the documentation for using it in a mobile web app are well documented with Facebook they TOTALLY dropped the ball on providing any direction on using it with a native iPhone app and they don't provide an updated SDK.

I could one of three things: 1. Use the old Facebook Connect which should still work for the forseeable future, but as stated above has too many issues that I don't want to deal with and they could drop support at any moment. 2. Wait for Facebook to publish a new SDK, but how long would it take them 3. Just figure it out myself and have a flexible solution that didn't relay any third party framework.  I went with option 3.
The first thing you need to do is setup your app with Facebook.  Second, you will need to create a "callback" page that Facebook will send the request back to once the appropriate code and token has been given to your original request.  Third, once you have gotten the access_token from Facebook then you need to put it in a DOM object. This is important so that you can retrieve it via the UIWebview's javascript string evaluation and then finally save the access_token in NSUserDefaults for any subsequent requests.  In my case I wanted to get a list of the currently logged in friends.  Instead of having to go through the callbacks and delegate methods associated with the FBConnect SDK I now have user's login via OAuth and I make a call to, https://graph.facebook.com/me/friends, and get a JSON response of what I need.  Simple. Beautiful.
Callback Example (PHP):

Custom ViewController (I am not including setting up the uiwebview. I assume you already know how to do that):