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).     


Stay In and Vote

By: Kyle Riordan

On my T ride (or subway, metro, tube whatever your vernacular) I spotted a notice among the ads alerting riders of a town hall meeting to discuss a proposed raise in fare prices.  Yes I live in a city that still has town hall meetings - I know, “How quaint.”  This being yet another hike in price, my initial reaction was boy I’d like to go down there and give them a piece of my mind. But then I remembered I have a job, girlfriend, dog, friends and family that occupy just about all the time that I am not sleeping; really the likelihood of me following up on this (and casting a vote if there is one) is pretty minimal.  Let’s face it, I’m not going to do it and the proposition will likely pass forcing riders to dole out more cash…again.  Then I thought, there has to be a better way.

If you have read any of my, or other Strategy Services members’ blogs  you’ve probably already guessed the way, APIs.  Now before you dismissively say, “Sure, sure, APIs are always the way,” let me take a step back to explain.  My sentiment of being too busy to engage is by no means unique.  I bet you have missed numerous local elections and votes due to work, travel and prior engagements.  One look at the voter turnout rates for the last presidential election really bears this out.  Are we really that apathetic?  I don’t think we are; I think we are that preoccupied. 

So how can APIs help?  In short, APIs specifically telco APIs, can help bring the polls to you.  Wouldn’t it be so much easier to cast your vote if that vote was presented to you on your mobile phone or connected device?  Telco APIs can help deliver this invaluable service by providing messaging, location and user identification information.  

The messaging aspect is likely pretty self-explanatory.  Instead of you leaving work early or missing whatever other engagement you had to schlep yourself over to the polls and check some boxes with your vote, those check boxes can be delivered to you on your phone or connected device using telco SMS/MMS messaging.  Using telco messaging APIs would allow for states and districts to engage not just smartphone users but standard mobile phones, delivering poll questions in text form and allowing users to text in responses to cast their vote.  It might be a bit more clunky than the smartphone alternative, but its definitely less clunky than waiting in a long line in the rain to mark a piece a paper and deposit it in a voting machine that looks like it was made in the 1970’s. 

People want to vote, but they need an easier way to get engaged. Look at the mobile device saturation rates in the US; with this additional conduit into the voting booth the voter turnout rates are bound to go up.  Voting would not only be easier but more reflective of the general public’s will. 

Of course there are some concerns.  What happens when you have voters outside their designated geographies, or my pesky nephew seeing the voting prompt picks up my phone and casts my vote for Taft?  This is where some of these other telco services like Location and User Identification information come into play. 

With location information provided by telcos ballot questions can be presented to voters only for their district.  If for some reason voters roam outside of their district’s boundaries while casting the vote the telcos could power notifications both to the voter and district to enable shut off, or designate the vote cast to the absentee ballots, now counting it only if in district voting margins could be swayed in one direction or the other by absentees.  Better yet, now with the expanded level of voting enabled these votes could be considered in district votes as opposed to absentee, limiting absentee ballots.

But how can the districts be sure that the people actually sending their votes from their phones are who they claim to be?  That is where User Profile information comes into play.  The telcos’ already have data points like our names, addresses, credit card information and probably in some instances our Social Security Numbers.  We’ve given that information freely (more or less) so now lets make it useful for us as citizens.  When submitting a vote through a connected device users could be required to input some sort of identifiable information that either telcos or the state itself would then be able to verify. 

Delivering this information to the state opens up an array of input options: Social Security Number, driver’s license number, passport, you name it.  And for those states with their newfound photo identification requirements, telcos can deliver that too via MMS.  Submit some sort of photo identification number in conjunction with a picture (no duckface selfies please) taken at the time of the vote that the state can cross-reference and voila you’ve met even the most stringent of voter identification requirements.

It’s 2014, we have connected cows, internet ready egg trays and even smart homes that can recognized us as we approach.  Why then are we still voting like we did when powdered wigs and tricornes were in style?  We need a ballot box that comes to us not the other way around.  Let’s demand it from our local and state governments now so one day soon we can all, “Stay in and vote.” 

Smart Farms: Planting the Seeds of the Future

By: Kyle Riordan

It seems that the Internet of Things (IOT) is infiltrating every industry (and in this blogger’s humble opinion, that’s a good thing).  We have seen this concept take hold in some familiar places, our homes, our cars, our cities and our factories; but what about our farms?  That’s right farming, one of the few industries that many of us probably assumed to be relatively stagnant in terms of technology is seeing its own revolution in what Forbes has dubbed the “Internet of Cows.”  As a people we have moved from the agrarian age to the industrial age to the digital age, and no longer shall our farms be left behind.

You may be asking yourself, “How can two so seemingly different concepts, digital technology and agriculture, find synergy in the ordinary moocow?”  The answer is of course data.  Data that can be derived from the fields, the water, the air and yes even the livestock to keep farmers better informed of their land, crops and animals. There are soil monitors, atmospheric monitors, aerial drones and animal tags being deployed on farms around the world to help farmers make better decisions.  Soil monitors can detect variables like ground temperature and moisture levels.  Atmospheric monitors can detect weather conditions in pinpointed locations.  Flyover drones can indicate if seeds have sprouted and animal monitors can track not just location but also provide indicators of potential illness.

At an industry wide level, the goals and benefits of all this is substantial.  Smart farming is actively trying to make our farms less detrimental to the environment by increasing crop yields, reducing water consumption, and streamlining farming processes.  Lofty and noble endeavors no doubt, but it can also help farms improve the bottom line. 

Let’s take the example of the connected cow.  A study conducted by the Cow Tracking Project found that each case of mastitis (a potentially fatal infection of the udder) costs farmers somewhere around £300.  With a smart tagging system used to monitor individual cows and their behavior farmers can be alerted to early indicators, make adjustments and hopefully avoid the illness.  This not only saves the farmer some money but also keeps the cow healthier and happier.  Multiply this out across a herd and the savings (in terms of both money and suffering) really start to add up.

The key is connecting all this data and delivering it to farmers in a manner that is both easily consumable and actionable.  The connectivity is precisely the area where telcos can fit in (and some already have with Verizon very much leading the charge through its Powerful Answers initiative).  There is an abundance of monitoring tools out there but not all of them offer the same level of connectivity.  Some require specific transmitters to transfer data, others require farmers to physically check stations, and some even require farmers to call in to toll free numbers to get current readings.  This lattermost instance is one where the telco use case fits in two fold.  Firstly providing the connectivity to transmit the data over the carriers cellular network and secondly by offering SMS and MMS APIs to deliver useful messages and alerts to farmers on any of their connected devices.  With the proper analytics tools evaluating the collected data the messages that are delivered can go beyond mere data readouts to active alerts warning farmers of potential problems. 

Like so many other industries, farms are getting smarter.  There are more tools than ever at farmers’ disposal to help them monitor their fields, and track their animals.  But just harvesting the data is not enough, it needs to be delivered in a time and manner that is actionable to help farmers make better decisions about their land and livestock.  With both their networks and APIs telcos can be a key enabler here helping the agricultural industry join the IOT.  Moo-ve over (sorry had to do it) old farms, the connected cows are coming home.