Cory Wiles Blog

If You Blog It They Will Come 
Tags


Filed under

twitter

 
May 27, 2010

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.

Loading mentions Retweet
Filed under  //   api   facebook   google   json   oauth   open graph   twitter  

Comments [0]

April 15, 2010

To Kill A Mocking Bird Called "Your Twitter App"

Over the past week there has been quite a bit of news coming out of the Twitter HQ. First it was announced that Twitter has acquired Tweetie and subsequently hired it's author Loren Brichter.  They also have launched the promoted tweet service and for you real bird watchers out there the ability to add meta data to tweets using the API.  Finally, it was confirmed that Twitter is going to launch their own URL shortener and stop using bit.ly.  A recently published article on Mashable summaries one tech startup's frustration with the announcement of Twitter now coming out with it's own "official" Twitter client. Why is there so much frustration? Because developers, at times, feel they have been sabotaged by the very companies they are using.  Just to be clear, they are upset because a service that Twitter owns, that they allow developers to use for free, is now being used by the very company that created it in the first place to promote their own brand!

I'm just saying...

I am developer and know what it is like to have that great idea or great app and to have some MUCH bigger/better company come along and launch their own version which inevitably kills mine before it got off the ground.  However, those are the ropes.  Don't put all your "1"'s and "0"'s into one app or service.  That goes for everything in life.  This animosity towards Twitter, and any other information service, is quite misdirected.  As mentioned earlier, Twitter didn't go out and build their own app, they chose, quite possible the best Twitter client in the AppStore today.  Did developers really expect Twitter to NOT have an official app.  I am surprised it has taken them this long.  That is like Apple releasing the iPod, but not iTunes.

What does that really mean? If you create something that is TRULY great then there is a good possibility that it will get picked up.  Just look at all the startups and other mashups that have been acquired by big companies lately. Twitter has just released a site for developers that will aid the creation of new mashups and services to use with the information they provide not hinder innovation.

It is an unfortunate price that one has to pay when the service you rely on for your mashup comes out with their own official app that does the same thing and my sympathies are definitely with you, but if all you do is rely on that ONE great idea then you weren't going to last that long anyway.

Loading mentions Retweet
Filed under  //   iphone   mashups   twitter  

Comments [0]

September 8, 2009

Automate Adding Twitter Followers with Zend Framework

Adding followers to a user one at a time is sometimes a VERY lengthy process.  Last night the question was posed to me if there was a way to automate adding followers from users who follow someone else.

Example scenario:
John Doe follows Jane Doe
John Doe wants to follow at 600 followers of Jane Doe

Unfortunately, the Zend_Service_Twitter class doesn't offer any functionality to retrieve a list of followers from another user, but I was able to extend the class and add the functionality.

The particular user that I chose to test has roughly 6,000 users.  My client didn't want all 6,000, but the first 200.  Within 10 minutes the new custom class was written,  the script ran, and now my client was now following 200 new people of like mind. :)

I plan on submitting the feature request to the Zend Framework gurus to have the ability to find followers from other users so that it can be apart of the main service.

Until then here is the class and script:

require_once 'Zend/Service/Twitter.php';

class CW_Twitter extends Zend_Service_Twitter {

  public function __construct($username, $password) {
    parent::__construct($username, $password);
  }

  public function getOtherUserFriends($name) {
        $this->_init();
        $path = '/followers/ids/' . $name . '.json';
        $response = $this->restGet($path);
        return $response->getBody();
  }

}

$twitter = new CW_Twitter('username', 'password');
$response = $twitter->getOtherUserFriends('friendusername');

$arrayObject = new ArrayObject(Zend_Json::decode($response));
$limitIterator = new LimitIterator($arrayObject->getIterator(), 0, 200);

    foreach ($limitIterator as $value):
      $twitter->friendship->create($limitIterator->current());
    endforeach;

Loading mentions Retweet
Filed under  //   apis   automation   custom apis   twitter   zend framework  

Comments [0]