What’s an API?

I hear this question a lot. Well, actually, I hear people using this term incorrectly a lot and so I’m asking the question for them here. I apologize in advance to my engineering colleagues who may have justifiable grievances with my oversimplified analogy but I’m targeting a non-technical audience for this post. 

To understand an API, first think of yourself as owning a restaurant. You offer guests (random visitors without any documentation of identity) a good meal.  To provide that meal you have ingredients stocked in the pantry, refrigerators, freezers, etc. and you have a bunch of tools, equipment and supplies to cook and serve the meal.  

Now, when guests arrive do you invite them back to the kitchen to see your ingredients and make for themselves any meal they wish?  Of course not.  And why not?  As you probably already know, doing so would mean every request is likely a unique process that is not easily repeatable, there’s no guarantee a guest knows how to assemble ingredients into a tasty combination and your operations might be irreparably damaged because of guests mucking with equipment or exhausting key ingredients. 

So what do you do?  You publish a menu with the combinations of ingredients you can efficiently produce with a team of skilled people following specific methods like boil, bake, fry, toast, etc. 

Wait, what does this have to do with an API?  An API simikar in that you are saying…

I have some ingredients (raw data)

I can run some methods on them (get, put, post, delete, etc.)

I have a menu of combinations of those methods I am willing to offer you because I think you’ll like them (the API)

So, an API is analogous to a menu of items in your restaurant.

And the people in your restaurant are those fantastic engineers who built the code to make the methods run automagically each time someone requests something via your API. 

Why my android experiment failed

I tried really really hard to be the biggest Android fan boy there is, but I gave up after a month.  I went back to iOS feeling like I returned to a more predictable, more reliable operating system even if that meant giving up some of the sexiness from the Android days.  At the end of the experiment, I felt the hurdles for customizing and managing all that sexiness was just too much for this time-crunched consumer to handle.  I decided it was better to accept that Apple figured it all out for me (mostly) rather than have to do it myself on Android.  Here are the main reasons I went back:

  1. Time Cost of customizing – the time it took to customize and manage virtually everything in Android was just too much work.   I thought it was great to have lots more features and controls, but, really, it’s a phone not an airplane and I’m not a professional pilot.  I have a day job.  If all that makes sense to you, then I have some land in Siberia I want to sell you.
  2. Data sync all or nothing – the data sync features of Android are “all or nothing” meaning I could not suppress synching calendar and contacts from my almost-never-used Gmail account.  I have a Gmail account for one reason only – to access some Google services that are not available with my corporate Google Apps account.  However, I keep all my calendar and contacts in my Google Apps account so the items in my Gmail account (though there are not many) are all cruft.  I don’t need more cruft.
  3. No universal inbox – I created corporate mail with Exchange using the mail app.  The mail app doesn’t support Gmail accounts so I created Google Apps account and my Gmail account using the Gmail app.   Therefore, I needed to check two different apps to get all my mail.  Enough said on that one.
  4. Ui inconsistencies – It’s great that Android is the wild-west when it comes to opening the distribution platform.  It stinks that everyone can shoot up the UI any way they want without a consistency review from someone who manages a published set of standards.  As cumbersome (and you might say, controlling, big-brother-ish and oppressive) the Apple app review process is, I found myself longing for someone to bring order to the UI inconsistencies on Android.
  5. General beauty — Generally, Android is beautiful in the sense it’s a world of controlled anarchy.  But it ended up being a little too much instability for me.

All that said, I’ve missed how Google Voice works on Android where it effectively takes over the phone and is the primary app for sending/receiving calls so you don’t use up your minutes.  Actually, there’s a setting for that.  Several settings that can be used in varying ways…..but I digress.  On iOS Google Voice is merely a “click to call” feature that routes calls through the Google phone network (if it exists, not sure) and you end up using your phone and minutes for these local calls.

Bottom line: If iOS is the “there’s an app for that” culture, then Android is “there’s a setting for that” culture.  For my usage patterns though, I have problems that can be solved with apps, not settings.

My experience with Chrome for iOS

I’ve been using Chrome on my iPhone since it became available over a month ago. Here are positives and negatives from my point of view.


The best part of Chrome for iOS is the integration with Chrome “as a platform.”  That means I can use Chrome on multiple devices and leverage the Google Sync features tied to my Gmail account.  Here’s the setting in Chrome for iOS:


As a result, I can see my bookmarks from other devices:


And reports on when/where my information was last synced:


The multiple tab view on Chrome for iOS is also efficient.  You can click the tab icon in the top right and see all active tabs.  You can scroll up/down easily and Chrome for iOS with automatically slide the tabs so 3 show at one time.  Also, you can swipe any active tab (not in the all-tab view) left or right to quickly switch tabs.  That’s a lot easier than opening all pages and swiping to the desired one as in Safari for iOS.




Lastly, I can see the usual icons for recently-closed tabs here:



One negative, but a really annoying one, is that my bookmarks are at least 3 clicks away. I need to open the context menu, click bookmarks and then click the bookmark I want to visit. That’s translates into a lot of clicking every day. Luckily, the tab swiping feature lets me keep all my frequently-visited tabs open at once and easily switch between them, which is faster than opening bookmarks.


Yes it’s possible, but is it legal?

A client recently experienced a Denial of Service (Dos) attack….except it originated from a partner! Well, not an authorized partner. Turns out a to-remain-nameless financial aggregation company asks their customers to provide login credentials to their financial websites. They then use the credentials to write a script that simulates a log in on their customer’s behalf and retrieves balance and payoff information to include in the aggregated financial report. There are a few problems with this:

  1. The aggregator simulates the login in a batch process, sometimes hitting a single financial institution with 10’s of thousands of requests in a short period of time, which behaves a lot like a denial of service attack
  2. The fact an individual shared login credentials with a third party (the aggregator) is usually against the Terms of Use with their financial partner
  3. The login simulation can be easily disrupted since it relies on open access to a public website, which is not a quality service to offer customers.

In my client’s case, they discovered the unauthorized access to their site and opted to block all traffic from the aggregator’s services. This left the aggregator in a precarious spot — service cut off to their customer and no leverage to negotiate a way to get back access to the financial site. They aggregator asked nicely for access to be reopened, and my client is considering it, but two months later they are still waiting.