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.