This Month in APIs - Just the Important Parts

Payment Integrations

By: Intel Mashery Strategy Services Team

We’ve all been using our credit cards to make online purchases for the better part of the last fifteen years. There’s a general workflow we’ve all come to expect - you add items to your virtual cart, fill out a form with all of your personal information and then cross your fingers in hoping the transaction went through successfully. Moments later an e-mail confirmation seals the deal and you wait to receive your shipment. This general workflow and process has mostly remained unchanged over this entire decade plus period; an eternity in the realm of innovation. 

The biggest news to hit September in the payment industry was the introduction of Apple Pay alongside the new iPhone 6 and 6 Plus. Both of which are Apple’s first smartphones to feature NFC (Near Field Communication) enabling iPhone users to pay for their goods by just using their smartphones. While Google Wallet and other services have existed for some time, many believe mass adoption will now start to take place thanks to Apple’s partnerships with large banks like Chase and Citibank.

APIs are accelerating the use of Apple Pay and payment integrations. Social media is the next venture to capture your hard earned dollar. If the process is simplified and easy whilst still being secure, why not?

Facebook Buy Button 

Stripe is a 150-person startup and its entire business model revolves around easily integrating and accepting payments via APIs They have partnered with Facebook to allow for quick and easy purchasing right on Facebook. With this new integration and partnership, Facebook will empower their users to purchase goods directly through their newsfeed with an integrated “Buy” button. Just as one would “Like” a particular story, through the use of Stripe’s APIs and the new “Buy” button, a user can purchase goods without ever leaving their respective newsfeed.

Twitter Buy Button

Without any surprise, Twitter is also incorporating this level of integration into its timeline. Again, users will have the ability to purchase goods directly through their Twitter feed without ever having to leave the app. Much like the setup process for Apple Pay, a user would setup their payment preferences one time, and then have the ability to quickly purchase items available in their respective feeds without having to enter in all of their information and go through the now-archaic workflow of online transactions.


Further demonstrating how APIs are being used to provide new innovative ways to buy things online, Amazon has unveiled a new interesting concept through the use of a hashtag on Twitter. Basically, if you’re browsing through Twitter and come across a product or item you’d like to purchase, you can Reply to that tweet with the hashtag, #AmazonCart and it will be automatically added to your Amazon shopping cart. While this still plays into the model of going to Amazon and performing a checkout, it accelerates the notion of seeing a product you want via social media and being able to successfully purchase it through a trusted vendor. I’m sure Amazon will want to one day include their 1-click Buy it Now option with Twitter as well. Perhaps we’ll see that partnership open up as well.

Many of these payment integrations aim to make the entire process easier. Historically, one would have to sign up to become an authorized merchant for the respective credit card companies, and then manually setup the workflow and processes to ensure they were PCI Compliant, securely obtained all the necessary payment information and correctly handle payments along with any errors that may occur in the form. Stripe, Braintree (PayPal), Google Wallet, and now Apple Pay are looking to disrupt the payment space. 

Factoring in the Internet-of-Things and having a connected everything, perhaps more devices and appliances can incorporate “Buy” buttons of their own. With the use of the appropriate APIs and the necessary up-front validation of authorizing payments, the potential increases tenfold for ease and smart purchasing. An example could be when your cat’s dry-food auto-feeder reaches below a certain level, more food could be ordered automatically. Or, consequently the device could notify you on your smartphone that the food has run low immediately followed by a “Buy More” button to re-purchase another bag of dry-food.

This opens up opportunities for healthcare as your provider could opt for you to purchase prescription-based medicine through a mailed prescription system versus going to the local drugstore via their smartphone app. The app could potentially keep track of when you’ve been prescribed new medicine and again – just a simple click of “Fill” or “Refill” button could be used to streamline this entire process. Not only would you be getting insurance approved meds, but all of the transactional work would be taken care of removing the hassle of figuring out who paid what and where.

The Next Gen Living Room

By: Rahul Gilani

When it comes to video games one generally thinks of vivid graphics, high scores, and yelling at one another through fierce competition. The previous and current generation of video game consoles do quite a bit more than just playing games in surround sound and high definition. They feature rich media and entertainment apps from sports news to streaming full-length movies. Of course, all of this is accomplished through seamless integration powered by APIs running in the background. 

Microsoft and Sony are the leaders in the living room space. Both video game consoles aim to be the centralized media and entertainment hub for the living room. While they both offer a decent amount of content and access right out of the box, what would happen if they opened up their platforms a bit more?  Currently, one would have to be a reputable gaming studio or recognizable brand to have an app added in this next gen marketplace. For the likes of companies like ESPN and Netflix, two household brands with enough followers to make an impact it makes sense for Microsoft and Sony to enable their consoles to utilize these 3rd party apps to extend the functionality of these primarily gaming consoles. 

But what about the independent developer who believes he/she has an interesting or helpful idea to bring to your living room? What hurdles would one need to jump to get an application approved for distribution on the latest and greatest gaming machines? Unfortunately, much of that information is difficult to find, but Microsoft and Sony are taking steps to make it a bit clearer and remove some of the obstacles. 

If the console makers created a more accessible “App Store” for their Xboxes and PlayStations, more developers could reach the rather untapped living room market. We’ve seen many devices that work in the living room, the Apple TV, Smart TVs, Connected Blu-Ray players - short of the Roku player, most of these interfaces have had rather closed systems and only provide what the manufacturers determine should be available. I believe it’s time to open these APIs up, and to allow developers to unleash the untapped potential of the living room. Additional revenue, whether it’s from the apps themselves or through advertising has immense potential. 

It appears that Microsoft at least had the intentions of going down this route a bit when it announced its latest console, the Xbox One, in  early 2013. The aim was to have the Xbox One be the Internet-of-Things “hub” for your house. It certainly has the connectivity and horsepower to run that gamut of devices. Microsoft had dubbed it “Home 2.0” but due to a lack of sales, a change in leadership and realizing the core audience of the Xbox platform felt abandoned, Microsoft needed to right the ship and focus on gaming first. Perhaps we’ll see this Home 2.0 initiative in the coming years along with an App Store.

The APIs are there. The console manufacturers just need to embrace the developers more and start to think bigger. Even Apple needs to open up the App Store for their Apple TV. It’s running iOS as the iPhone and iPad already do, but only established partnerships with approved content can be added as additional “channels” to the Apple TV. Tim Cook, Apple’s CEO, recently stated that the Apple TV isn’t a hobby anymore with more than 20 million users. Apple is all about profit margins. Let the 20 million consumers purchase 3rd party apps for the TV and expand the reach and capability of the device. Microsoft and Sony probably see this untapped potential all the time and are in the perfect position to start utilizing their powerful gaming machines to open up the living room.  Now these companies just need to embrace the developers as they have in other markets and watch the creativity and connectivity flourish, while hopefully increasing revenues and profits as well.

This Month in APIs - Just the Important Parts

Open vs. Closed Programs – The Renewed Debate

By: Intel Mashery Strategy Services Team

For as long as APIs have been around there seems to have been a persistent question, “How do we best leverage these? Is it best to keep them internal, offer them to partners or open them up to everyone?”  Deciding on who gets to use your API and the content they are allowed to access is one of the most important questions a company can ask itself when thinking about it’s API program.  It is a pivotal question that has a cascading effect on all other decisions that go into the program. 

This past month saw some notable API programs electing to shift their Open vs. Closed Program strategy with both ESPN and Aetna electing to shutter the doors on their Open programs. But it wasn’t all misfortune for the developer community as one highly anticipated program rolled into the Open market with Uber launching its API to open developers.  That’s a lot to take in so let’s take a quick look at what happened.

Carepass Dropped

In the waning days of August Aetna announced that it would officially be discontinuing its Carepass program by the end of 2014.  Not surprisingly, this was deemed pretty big news, particularly within the healthcare space.  Offering explanation to its users and the general public regarding the reasoning behind this decision, Aetna cited a number of different factors. 

One of which was a lack of consumer buy-in from both Aetna users and those outside their network.  Like any other product in the market it doesn’t necessarily matter how great a product is itself - if consumers aren’t interested, success is going to be a challenge.  Unfortunately the lack of widespread buy-in permeated into the provider market as well with Forrester’s Peter Mueller citing a lack of integration with EHR (Electronic Health Record) systems as one of the primary contributors to a lack of traction. 

The biggest culprit though may have had nothing to do with the outside world’s acceptance of the program but rather Aetna’s own internal view of it.  According to Mueller, Carepass “didn’t have the buy-in from all parts of the organization.”  When this happens it doesn’t matter what type of developer a program targets, the road to success is going to be an uphill battle. 

ESPN Retires Its Open Program

Like Aetna, ESPN has elected to discontinue its Open developer program.  ESPN announced its closure in July noting it will no longer be issuing 3rd party developer keys.  December of this year has been targeted for full shutdown.  ESPN cited a re-alignment of resources to core ESPN products as one of the primary reasons behind the closure.

Your Uber API Has Arrived

But don’t worry developers it isn’t all, “Farewell (insert API program), we barely knew thee.” Uber is opening up its API to third party developers giving you a chance to integrate its functionality directly into your applications.  For Uber, this new phase in its API program is designed to help expand its reach and attain new customers - allowing end users to access and try Uber from outside its own application.  And there is of course something in it for the developer too as Uber is giving developers that integrate the API some free credits.  The amount thus far is undisclosed but hey cab fare isn’t cheap, it’s a nice little perk for sure.

What do these closings and openings mean for the Open vs. Closed debate?  Well, very little in the grand scheme of things.  What the two closings represent is a shift in how the two relevant companies view their APIs and where they see the most value.  Strictly speaking, just because Aetna and ESPN do not think it is in their best interest to continue offering Open APIs does not mean that no company should.  And just because Uber wants to offer its API to the world doesn’t mean that would be the right choice for your company. 

These instances show is how important it is to take a step back and really look at the value proposition behind your API keeping in mind that the value proposition is a two way street.  Sure third party developers may get a ton of value from what you have to offer but there has to be something in it for your company as well.  If there isn’t, that is where the problems start to arise and getting the overall organization to support the program is going to be exceptionally difficult.

There are plenty of arguments to be made for Open, 3rd party developer programs.  They can be a great way for a start-up to gain recognition.  They can expand the reach of a company’s customer base integrating into new apps and ultimately reaching more people.  They can be a great recruiting tool; if someone designs a killer app using your API, wouldn’t you love to contact and possibly hire that person?  You can go to hackathons, particularly college hacks and find the best and brightest, picking up great interns and hopefully great new employees.  There is so much you can do but the real question is what should you do?  All these things are great but when asking, “Does doing this bring me some sort of value?” is answered with a “no” then simply put, an Open program may not be for you.  And that by the way is fine; as noted previously opening up your API is a two way street- if everyone does not benefit then ultimately no one wins.

Particularly with the closings people seem to be asking, “What does this mean for APIs in general and within the relevant industries?”  Ultimately it means very little.  APIs or APIs within healthcare is too general and widespread of a topic for one company, even a massive one to have a uniformly indicative effect on the entire industry.  The value proposition for an API, just like any other product a company offers, is specific to a certain market and determining what that market is beforehand and aligning the strategy accordingly is pivotal to success.

5 Things to Understand About Successful “Open” APIs

This guest post comes from Intel’s Chuck Freedman API Strategist and Director of Vertical Insights, always looking at the benefits of APIs from many perspectives.

Take a closer look at the recently celebrated and deservedly promising Uber Open API launch and you won’t see a free-for-all service. There’s nothing about this platform, or any successful platform for that matter, that says “Here are our APIs and do whatever with them you please.”

To launch a successful platform, the true use of Open in the API sense is to selectively expose the very same services, content or data a company uses itself. This is motivated by partner demand and a calculated understanding that the platform can ultimately offer something of value to those outside the organization.

Let’s walk through some common misconceptions I often hear regarding successful, Open API programs:

1)   Open APIs are not truly “open:”

They are not truly open, rather they are well-managed APIs, guarded, controlled and managed by keys which let the platform owners determine who can access the platform and at what frequency. Think of how theme parks like Disney World “open.” Guests can’t just flock in and enjoy rides and food without first passing through ticket gates. Successful open API programs rely on similar gates to control the flow of access to their platform.

Looking at the newly launched Uber developer page you’ll find documentation and tutorials. However, you won’t be able to properly make API calls into the platform without first registering your app and receiving an authorization key to append to all calls you’ll make going forward (and rightfully so). This is how the platform team, using proper tools, will manage access while also understanding API usage through reporting and other techniques. 

2)   Open API programs never seem to offer up the raw access to services or data they’ve often used internally:

With an approach similar to how a product is managed, good platform teams will understand how external partners and developers may need to use their API and craft polished endpoints and data. The result gives intended developers a better starting point, a refined approach to engage the platform and induces more quality integrations.

Although we can’t peek into see how platforms are consumed internally, for those of us who have worked on platforms know this: it’s easy to recognize, in the case of Uber and other successful app companies that have launched platforms, the platform services were being used and iterated internally for some time. Bottom line – it’s no accident that after years of using their own service, a platform openly launches in an elegant manner with the success of its developers in mind.

3)   Many promising Open platforms will launch with integration and app ideas ready to share:

A mark of successful platforms has been their ability to inspire and cultivate valuable apps from their newfound developer communities. A good developer portal or blog post will even challenge developers with examples and listed possibilities of what can be done.

Of course, the Uber platform opens with a list of ways the Uber API can add value to your app (Uber API). Referencing either existing partnerships or those the platform team envisions.  The list shows careful thought into the launch of the platform and invites partners and developers to expand on what’s totally possible.

4)   Some Open APIs don’t last forever: 

Fresh off of its launch, Uber shows no signs of slowing down. However, as developers of previously “Open” platforms like Netflix, ESPN and Twitter would tell you, “Code-with-caution.”  

Realize a great Open platform is launched to create mutual value. For the developer, you’re getting access to features or content that may be well beyond your reach or ability to reproduce. For the platform, opening APIs is about exploration, creating value for existing or extended users and maybe the potential/intent to drive some revenue in the process. Accepting a key to an Open program is a bit of a contract and if partners and developers hold up their end of the bargain the platform will remain Open to drive innovation.

5)   Open API access usually represents a wildcard use of the platform: 

In most cases, the platform is actually being used by the company itself – for their own purposes. Often, the API is designed to give internal groups, or outside vendors, controlled access to the platform in support of scalable development of the company’s own web, mobile and desktop app integrations. After internal use, a successful platform exists to also support targeted partner use, which may be paid for or intended to bring mutual value to the company’s business partners.

Often, the “Open” aspect of the platform is a byproduct of these internal and partner use cases, making select services available to drive innovation. A good developer portal and solid documentation support easy discoverability to companies and developers. Using advanced tools, authorization keys can be auto-provisioned granting sufficient, but limited access to allow for these wildcard integrations.

Whether fostering smaller companies to build new things, Open platforms can really succeed when apps built through open access can graduate to recognized and valuable partner integrations. 

There are many arguments made among top API strategists and evangelists that more platforms should be Open. For a platform to maintain success in making APIs available outside its organization a strong set of strategies and tools need to be in place. One of the best things a platform can do when considering an “Open” launch is to understand the possibilities of what 3rd party partners and developers can actually bring. If the platform can be beneficial to all parties, and the company is open to driving innovation beyond itself and its partners, then those API ticket gates should be “Opened”.

Follow Chuck Freedman on Twitter and read more of his posts from Intel’s Services Division blog. 

This Month in APIs - Just the Important Parts

Smarter Travel

By: Kyle Riordan 

On the Strategy Services team, we spend a great deal of time and effort keeping our fingers on the pulse of the API and tech industry.  We’re sure you do too, otherwise why would you be here reading this?  It can’t be for my witty quips - they’re just not that clever.  But, for even the most serial tech readers out there, the rate with which the industry moves is just astonishing; new start ups, acquisitions, emerging technologies, APIs and apps that seemingly spring up out of nowhere can all be a bit much to track.  It is one of the main parts of my profession and even I sometimes find it to be overwhelming.  

That is why we are launching a new effort as part of this blog to post a sort of “month in review.”  Though not an exhaustive summation of the past month (how could we possibly fit that into a single post?) it will serve as a sort of highlight reel showing you some of the more interesting things that have happened while we throw in our two cents.  A sort of SportsCenter Top 10 for the API space (sorry - no dunks in our version) designed to tell you a story without making you read a month’s worth of tech news.

For our first installment, we selected a topic that seems to be taking the travel and hospitality industry by storm: enabling access through our smartphones and wearables.  It seems every business segment within the industry, from trains to hotels, is looking to open new doors (both literally and figuratively) using consumers’ smartphones and wearable devices. Travel saw some interesting announcements from both the London Public Transport Network and SITA, while hospitality featured some amazing new plans for innovation from Hilton. That’s a pretty wide range of companies, and all of this in a single month! 

Old Transit – New Tix

The London Public Transport Network incorporates the world’s first underground railway system dating back over 150 years, but this old network is looking to become about as modern as subway systems come, integrating contactless mobile payments into its stations.  The update will allow users to pay their tube fair with any mobile device containing an NFC chip and mobile payment app linked to their back account.  Sorry iPhone users, no NFC chip for us - we have to stick to the old fashioned method.  Though not everyone will be able to use this new technology, it will certainly make the morning commute easier for those who can and cut down on the lines for everyone else. 

Air Aware Wearables

SITA is also looking to make the way you travel - how you fly in this case - easier.  Unlike London Transport though, SITA is looking beyond our phones to the growing interest and use in smart watches.  Just this past month SITA started exposing a new API designed for Android watch wearers.  Once adopted by the airlines, the API will enable passengers to receive alerts reminding them of flight time and location and allowing them to pull up their boarding pass and scan ready barcode with a couple of quick swipes.

Hilton Enhances the Mobile Experience

But what good is all this newly convenient travel if you don’t have an equally convenient experience once you arrive at your destination?  Hilton addressed that question by announcing they now allow smartphone users to select their room before check-in.  Users will be able to access photos of the room as well as the floor plan.  Topping that, they also plan to start rolling out smartphone powered room keys to its hotels in 2015.  A convenient option for people like me who always remember their phone, but never, ever remembers the key card left on the nightstand.  Oh, and good news fellow iPhone users - this initiative is designed for both Android and iOS users, so this is one we will actually be able to get in on.

The Little Things Lead to Greater Things

As July demonstrates, the travel industry is opening itself up to a whole new world of possibilities through its APIs.  Everyday travel, like your workweek subway ride, is getting easier, flying is becoming less of a hassle, and no longer will we have to walk back down to the main desk to explain that we lost our room key…again.   Looking at these instances in a vacuum, it is easy to see them as a nice little perk, a bit of convenience but really nothing earth shattering; and that’s probably true.  But, when we take a step back and realize the broader implications of initiatives like these, it speaks to the world to come, a world where normal events and occurrences are more often than not automated by the everyday items we wear on our person and keep in our pockets. 

That’s what APIs and the Internet of Things are currently enabling for us all.  Yes, for now, its just small niceties like our tube pass, boarding pass or room key, but this is only a tiny sample of the larger efforts the travel industry is undertaking, and virtually every other industry as well.  These small niceties over time will continue to pile on and, before long, we will be immersed in a world that interacts and responds to us even before we make any demand of it.  Think of that level of convenience in our homes, in our cars, when we are at work, when we travel and all the time and energy it will save us.  Some might see this vision as the embodiment in laziness, but it’s not - in fact it’s the opposite, offloading the menial tasks to machines so we can work more efficiently in the office and have more time outside of it to pursue our own interests in precisely the same way we automate tasks to our non-connected machines today.  Hey, you make a pot of coffee using a coffeemaker in the morning, don’t you? 

There are still a lot of challenges and questions that the industries emerging around the Internet of Things need to answer.  But, as they do, the rate with which we receive all of these “niceties” is only going to accelerate, and a connected automated world will be upon us before we know it. So, “All aboard!  Please keep your seatbacks and tray tables in their upright locked position.  And enjoy your connected stay.”

Contribution From: Rahul Gilani

Stop Talking About Hypermedia and REST - Start Building Adaptable APIs

By: Rob Zazueta

I had a brief moment of enlightenment at last week’s API Craft conference in Detroit while leading a session I titled “How Do We Help Developers Implement the APIs of Tomorrow (or Today)?” Many of the responses coming back from the crowd took some form of “use hypermedia.” Listening to these and seeking answers as to how to best communicate this to developers, I felt the need to stop the conversation to ask what I thought should be a simple question. 

“What is hypermedia?”

Many of us had spent the previous day listening to a panel of API experts talk about hypermedia and how the various response formats they created (JSON-LD, Hydra, Siren, HAL, etc.) addressed and supported it. In fact, I could see some of those same experts in the crowd standing before me, all of them searching for a way to express the right way to respond.

“Like, in one sentence?” piped one brave soul. “I don’t think you can do it in one sentence.” 

Another answered by describing it as “an API which can be documented without writing one single absolute URL or relative URL path,” which speaks to hypermedia’s apparent ability to self-document, but does little to explain exactly how that’s implemented. 

This should have been an easy question to answer, but it turns out even the experts grope for a description when pressed. For my part, I consider an API to support hypermedia when it does the following:

  • Each resource points to related resources and available actions using the method native to its protocol (i.e. using URIs over HTTP)
  • Each resource clearly defines its media type so a client knows what it’s parsing (i.e. by providing a MIME type in the “Content-Type” response header) and responds appropriately when requested to return a specific media type (i.e. when a client lists it specifically in the “Accepts” request header)
  • Each resource points to a machine-readable description of how to parse its media type. (i.e. through one of the many emerging API descriptor languages, such as I/O Docs, Swagger, RAML and Blueprint)

Few protocols outside of HTTP provide for this full set of actions, which is appropriate since the “H” in “HTTP” stands for “Hypertext”. In other words, it’s a protocol built specifically to deal with hypermedia. This becomes obvious once you realize that the most robust hypermedia client in the world today is the very browser you’re using to read this post.

To describe how a hypermedia API should operate, Brian Sletten suggested at last year’s REST Fest conference that you should ask yourself, “What Would the Browser Do?” Out of the box, most web browsers can handle the most common media types - the text-only text/html, text/xml and text/json media types, of course, but also image/jpeg, image/png and image/gif, which each define graphical image formats expressed in binary requiring special parsing to display. When greeted by a media type it doesn’t recognize - application/x-shockwave-flash, for example, which is used when an Adobe Flash object is being sent - most browsers have a facility to search for and install a plugin that can handle that media type inline with the rest of what it’s displaying. 

This makes the browser highly adaptable as new media types representing different technologies arise. So long as a plug-in has been created for the browser and the browser can find it, it will adjust. This adaptability is what has made the web a dominant standard over the last 20 years. It’s not the browsers, but their ability to use the hypermedia facilities used by servers to be able to adjust as new data types become available.  

I’ve attempted to express this in the NARWHL API design framework I developed earlier this year. NARWHL arose from my observation that development teams creating APIs were getting too caught up in the implementation details - what should the URIs look like? Should everything be expressed as links and traversed from the root, or should they be atomic? And what response format should we use? What if the format we choose doesn’t fit our model? 

NARWHL is intended to get past these details, providing a clear path forward on how to design an API that can change as business needs change and standards start to settle without disrupting client applications any more than necessary. While it accomplishes this by adhering to hypermedia constraints, the ultimate goal is to build adaptable APIs. Hypermedia is just the means, adaptability is the ends.  

Your URI layouts, response formats and descriptor language choice are implementation details - on that all the experts at API Craft could agree. The number of different ways you can create a RESTful API is many, varied and growing and shows no signs of settling down any time soon. If you are building an API intended to be used today, but are worried about whether it will still work tomorrow, allow me to calm your fears. Build the API today that best suits your needs and fits your model. Choose a descriptor language that best allows you to describe it. Make sure every response includes the Content-Type that represents it and make sure there’s a common way for a client to request the descriptor definition for that Content-Type (NARWHL recommends using a “Link” header in the response with the “rel” set to “service”, but I will soon be adding another recommendation that can complement or potentially replace that). And make sure you express every possible transition/action available to a resource as well as its related resources in the form of links, including the relationship (expressed using the “rel” parameter) and the method (i.e. “GET”, “PUT”, “POST” and “DELETE”). Encourage your client developers to trust your links, pay attention to your Content-Types, make use of the Accepts header and use your descriptor documents to parse your responses in real time.  

Following these simple rules today will ensure your API adapts to the needs of tomorrow. Free yourself from worrying too much about the implementation details and instead focus on modeling your API to provide flexible solutions that address the challenges your developer customers are solving. If you want to build a successful API, build an adaptable API.

Let a Sleeping Baby Lie

By: Devon Biondi

As a first time soon to be mother you can imagine that I have been inundated with advice; some good, some odd and, well, a few things in between.  It’s fairly easy to drive yourself mad making sense of it all, but, like most things, I have been relying on my good ol’ iPhone for shortcuts and it hasn’t let me down.  The technology around child rearing has made incredible advancements in just the past couple of years.  It seems every aspect of rearing a baby from conception to pregnancy to monitoring has progressed in leaps and bounds - and most of it can be controlled from your smartphone.  

If we flash back in time for a moment, the first baby monitor was invented in 1937 by the Zenith Radio Corporation as a reaction to the Lindbergh kidnapping in 1932.   It’s true, I can’t make this stuff up.  It was a two-part set: the “Guardian Ear” transmitter, which was plugged in near the infant’s crib, and the “Radio Nurse”, which was placed with the caregiver.  Unfortunately, it picked up quite a bit of unnecessary signals, so the monitor never became a must-have nursery item.  


Fast-forward to today and no nursery is complete without a video monitor, allowing panicky new parents to carefully monitor every noise and movement from their little one’s crib.  Dropcam, which is not exclusively a baby monitor, but a wireless camera you can control from your smartphone, has taken it a step farther by not only allowing two-way talk, but also detecting any strange movements in your nursery.  You can live stream to your phone as well as the web so that eager grandparents can always be spying checking in on you.  I was lucky enough to receive one of these from my awesome co-workers and, with Dropcam’s beta API program, I am sure there will be lots of great mashups in the near future.

However, the monitoring advancements don’t stop there.  At CES this year, our very own Intel announced that the Edison Chip would be used in the Mimo Baby Monitor.  


The Mimo is a onesie that you put on your infant to monitor breathing, temperature, the baby’s movements and sleep cycle.  The starter kit has a hefty price tag of $200, but, for peace of mind that your little one is safe, that seems like a steal to me.  While there are other similar devices out there, such as the still in stealth mode Sproutling and the slightly less well-designed Owlet, it seems that video monitors may soon be a thing of the past.  Again, as a new, slightly paranoid parent, the ability to monitor every aspect of my sleeping infant sounds amazing, but I’ll report back after my little one arrives.

Apple <3 Devs

By: Rahul Gilani

Monday marked the opening of the 25th World Wide Developers Conference (WWDC) for Apple. Led primarily by Apple CEO Tim Cook and Senior Vice President, Software Engineering, Craig Federighi, the two-hour presentation focused on the newest versions of Apple’s desktop and mobile operating systems and the developers that will shape them.

The changes coming to the newest version of OS X 10.10 Yosemite featured more customizations and integration with Notification Center, creating a sidebar that allows users to receive alerts and updates with a glance. Apple also showcased tighter integration within Spotlight - OS X’s search functionality - by returning web results and other sources in search results. For example, users that search a movie title will receive showtimes and theaters playing the feature. The core of the OS X update encourages more integration with desktop apps and connected sources across the web. Of course, none of this would be possible without usable APIs. 

Apple unveiled a plethora of new features for its mobile operating system, iOS 8, which will be publicly released later this fall. One of the most telling signs that Apple sees the value in unlocking more functionality for developers is the announcement of introducing 4,000 new APIs for integration at the OS level.

One of the new APIs that iOS 8 opens for developers is access to TouchID, Apple’s proprietary fingerprint scanner that was originally limited to unlocking the device and authenticating app purchases. Don’t we have enough passwords and logins to worry about? Those who have an iPhone 5s (or, presumably, future Apple devices to be unveiled later this year) will experience this added functionality. Of course, new integrations will depend on developers finding use-cases where a fingerprint ID makes life easier with their respective apps.

Much like what iOS’ Passbook did with movie tickets, boarding passes, and Starbucks, Apple unveiled HealthKit and HomeKit to provide centralized functionality for connected health and home applications respectively.

With the Internet of Things bringing sensors to everything, and the exponential adoption of wearables, the resulting trove of health, fitness, and activity data has spawned a multitude of new apps that track your well-being. Apple’s HealthKit will act as a centralized repository for all these health-related metrics that can be used to, hopefully, lead us all to healthier lives. 

Likewise, the HomeKit API intends to make your home smarter and up to par with things we’ve seen since we were children watching The Jetsons. The idea is to encourage app developers to incorporate additional hardware that will be installed throughout the home to assist with locks, lights, cameras, doors, thermostats, plugs and switches. HomeKit helps developers securely pair to and control devices, group them together and integrate with Siri for voice commands. In talking about this last feature, Craig Federighi suggested a scenario where you could tell Siri to “get ready for bed” and the associated app would lock the doors, set the thermostat and dim the lights. Right now, I have an automatic timer for my outside lights. While that’s certainly helpful, it’s not very smart, nor can anything else integrate with that switch.

Something that has been foreign to Apple devices until now are app level extension integrations., functionality Android devices have had for years. A user on an Android device can bring up a photo and share it with any other installed apps that have told the system they can work with it. In contrast, Apple limited the information that could be shared between applications to whichever services they chose for that year. By introducing extensions, each of these apps can talk to each other directly, raising the iOS integration level to that of Android.

Notification Center was a welcome addition to iOS, but it, too, has been lacking until this newest version. App developers will now be able to create dynamic widgets that can be added to the Notification Center. An example of this is ESPN showing the latest sports scores with a quick swipe down, resulting in real-time updates.

But the biggest reaction from the developer community came when Apple unveiled its new programming language, Swift. The language’s scripting-like syntax is intended to make developing apps for iOS and OS X easier and faster than its predecessor, Objective-C, whose verbosity and complexity was seen by many developers a bottleneck to adoption. Apple kept much of that complexity out of Swift and demoed an impressive “Playground” to get developers up and running in no time.

With 4,000 new iOS APIs, extensions, widgets, and Swift, Apple clearly demonstrated its commitment to developers is as strong as ever. 

The Connected K-9

By: Kyle Riordan

I’ll admit, not being from Silicon Valley had left me a bit skeptical of the whole “quantified dog” phenomenon. I mean, was this really something people were starting to do?  I love my dog, but I don’t need daily read outs of her activity on my phone.  It’s not really a big mystery to me; when I’m not there she mostly sleeps (that is after all how most dogs spend the majority of their time) and when I am, she enjoys her walks and play.  And for those who ask, “Well what about people with dogs that are overweight?”  I suppose you may have something there.  I’m a big believer in the idea that healthy dogs are happy dogs but I still fail to see how an app telling me that the pooch is at rest helps me correct this inactivity.  Unless that app has some way of making the dog want to get up and run around, the benefit of that information still eludes me.  To me, the remedy is seemingly pretty straightforward; if the dog is overweight; less food, more exercise, some combination of the two and if that does not work ask your vet if further tests are warranted.  Maybe I’m just too narrow minded or simplistic in my views of our K-9 friends or maybe there has just been something missing from the value proposition. 

It seems now though that Whistle may have an answer to this last point.  That answer is provided through what it is calling an “evolution” in its product with the WhistleGPS.  No longer will the monitor and accompanying app merely track your dog’s activity, now it will actually track your dog; as in its location.  That’s a value proposition I can get behind.  Sure you can always chip your dog, but not all those chips provide real-time location and many require someone actively scanning the dog to verify identity.  And besides all that, it’s pretty invasive on the pup.  With this update from Whistle you can always know where your dog is, even when it gets loose and is off to explore.

As you might be able to tell, I kind of like this update; I think its pretty cool.  But what I really find interesting about it is how Whistle is doing it.  If you are like me you’ve probably assumed it’s being done one of two ways, Bluetooth/WiFi or some form of IOT traditional wireless carrier integration.  The answer though may surprise you as it comes in the form of a new sub-GHz technology from Sigfox (when outside of Bluetooth/WiFi range).  The benefit of using this new network technology is that it exceeds the range provided by short range networks like Bluetooth but does not have the same burdensome costs that come with traditional carriers.  In other words, it’s the best of both worlds and could potentially be a revolutionary way of bringing data up into the cloud.  

If you’ve kept up with the Strategy Services blog in the past couple of months the excitement for this new technology may come as a surprise.  I personally have written a number of posts lauding traditional telcos as the potential answer to connecting more devices.  In many instances these providers are still the most effective solution.  For one, just like with your cellphone there’s the issue of network coverage and speeds.  The new sub-GHz technology only transmits 100 bits/second and is deployed in limited locations (unless you are in France) so might this new wireless connectivity work for your new “connected car?”  Probably not so much; at least not right now.  What it will work for though are fixed objects or ones with a relatively small variance in location.  The benefit is substantial; having that expanded range with lessened costs could be the launch point that gets more devices into the Internet of Things. 

Hey if we are already doing it for our dogs is it really that far fetched (get it?) to think we’ll start using it to connect our gas pumps, farms or bicycles?  All this (potential) connectivity opens up a new world of APIs and apps to enhance our lives.  With new connectivity models making the collection and cloud storage of data easier APIs become increasingly important.  APIs are how we put all that new data to good use; we can use it to find our lost dogs through our phones, find available parking through an app, better evaluate water/electric/natural gas consumption by a household, a neighborhood, even an entire city!  This new network technology can help make the data obtainable, APIs are what will make it useful.

So a post that starts off with quantified dogs ends up in smart cities and connected bikes.  That’s really one of the most amazing parts of the IOT; just how expansive it all really can be.  Virtually any device can be connected, and with more network options joining the fold those devices might all start getting connected sooner than we had anticipated.  Putting all that connectivity to good use requires good APIs.  And with the right APIs in place the IOT can enrich not just our lives but also the lives of our pets giving even our dogs something to smile about.


Hey, It’s Rahul

By: Rahul Gilani


I’d like to introduce myself as the newest contributor to Mashery’s Strategy Services blog. My name is Rahul and I have been with Mashery for just over two and a half years as a Client Solutions Manager (CSM) completing dozens of customer implementations across various verticals and industries.  As a CSM, I was the technical subject matter expert and implementation “Coach” to customers utilizing Mashery’s SaaS offering. My sole responsibility was to ensure any API program I was involved with achieved success.

I am excited to announce that I am joining the Mashery Strategy Services team as Manager, Platform Strategy. With comprehensive knowledge of Mashery‘s API Management Platform and exposure to numerous API programs under my belt, I am excited to bring additional depth to an already outstanding team. 

I truly love technology. APIs are driving the ever-evolving landscape of how technology interweaves with our daily lives. I’m excited to be at the forefront of things to come with the Internet-of-Things, as everything is quickly becoming connected.  On a personal side, I am a die-hard ice hockey fan, a gamer and an amateur photographer.  I recently earned my Master of Science degree from Boston University in Computer Information Systems and have an extensive background in multiple areas of the IT ecosystem ranging from mobile/telecommunications to web development. With all that being said, I hope to put the many facets of my background to good use as part of Mashery’s Strategy Services team. 

I look forward to posting more on this blog and communicating more with the technology community. Please feel free to say hello on Twitter (@rahulgilani).