Wrapper!

At last night's Austin Homegrown API meetup, I saw Jeff Brateman of PayPal speak on PayPal's SDK (Software Development Kit) offerings for its API (Application Programming Interface). It has one for iOS, one for Android, and one for Windows. The iOS one for example allows one to make purchases via PayPal at an iOS app which is sort of exotic as there is little otherwise available in the way of ecommerce in apps listed at Apple's App Store. In each environment everything you could do with an SDK you could just do by interacting directly with the API as all a PayPal SDK does is give you a blob of Java or Objective-C or whatever to wrap API calls and make them less painful to use. That said, Jeff asserted that more developers were using the SDKs than were directly interfacing with the API. There are a couple of reasons for this.

1. First is the DRY principal. Don't repeat yourself. SDKs wrapping APIs may minimize spaghetti.
2. Many developers desire to work with an API without knowing the whole of the domain. Why can't it just be easy? Maybe it can be if you just talk into an SDK, let it talk to the API, let the API talk back to the SDK, and then get stuff back from what the SDK itself gleams from the outside.
3. OAuth2 is used for authorization (are you who you say you are?) and authentication (are you supposed to be doing that?) and OAuth2 is a little bit painful to use outside of an SDK. If you write your own implementation against an OAuth2 API you will spend your first day just dealing with OAuth2. With OAuth2 you have a secret, or, if you do not have a secret, you are a "public client" and OAuth2 has approval and consent do-you-want-to-opt-in stuff baked into it. An SDK that uses OAuth2 makes it easy to fish for consent from a user without you having to figure out how to do it yourself.

card.io was brought up as a technology which PayPal bought. It allows you to take a photo of a credit card with a smartphone and have that act work in lieu of swiping a card in another scenario. The numbers in the photo are interpreted and the card is processed, all without adding new technology onto the devices we all already have. Another interesting aside: What keeps a credit card processor in business will boil down to its ability to prevent fraud and abuse while also not shutting out legitimate transactions. This is not trivial and doing it well is so tough that it is tough for one to establish oneself in this space. A story was told of how PayPal once blanket blocked transactions in a stream of transactions if all of the transactions appeared to come from the same IP address. In the name of blocking sinister traffic, they would act (after a few transactions made it through and they "saw the pattern") to just turn off access. Makes sense right? This backfired when, at a convention, many different parties legitimately tried to hit the API from the same wireless network at the convention's locale. I think this all happened for a presentation that gave a demo of the API. Embarrassing! To better deal with this sort of thing one has to consider geopositioning and triangulation. That has to come into the mix to make judgment calls on the legitimacy of traffic flooding in from a single IP address. This stuff isn't easy. PayPal does it well. They've learned and grown from tough mistakes (well, at least one), but don't think that any company can do what they do. Anyways, let me get back on topic. Tips for a good API-wrapping SDK included:

1. Try to make something future proof which means try to make something that can be given new features and functionality without it feeling like add-ons were obviously unplanned and originally oversights. Ideally, new features should be downwards compatible.
2. Small footprints are preferred. A forty megabyte SDK? Not so much. That could be bigger than the rest of one's application in some cases. Some users will want to keep it thin and you should empower them to do so.
3. Minimize external dependencies as much as possible. People just want to use SDKs and not stress. Instead of worrying about how to light a candle, whether it will blow out, and if it will start a fire, wouldn't you rather just be handed a flashlight?
   

Addendum 4/26/2014: authorization is "are you supposed to be doing that?" and authentication is "are you who you say you are?" not the other way around.