Recent Postings
April 4th, 2014

API Academy Goes to Asia

API Academy in AsiaStarting April 4, I’ll be on the road for close to two weeks. Along the way, I will have the honor of bringing the API Academy message of developer-focused, enterprise-scale API design and implementation to the cites of Seoul, Tokyo and Singapore. In each of these cities, we’ll be hosting a free half-day seminar covering some of the most popular topics the API Academy’s private, onsite training offers to companies the world over.

I will also have the chance to do some additional presentations and make new connections while on this trip. As much as I enjoy the workshops, it is the chance to connect with people I’ve only known online and to meet new ones that really makes these trips a great experience.

WWW 2014 in Seoul
While in Seoul, I will have the honor of presenting a peer-reviewed paper to the WS-REST2014 workshop, which is part of the World Wide Web Conference in Seoul. It is not often that I get the opportunity to speak at events of this caliber and I am also looking forward to catching up with several people who work on W3C projects – people I rarely get to meet in person.

There will also be an informal meet-up in Seoul on the evening of April 8 near the COEX complex where the WWW 2014 event is to be held and not far from the API Academy public workshop on the April 9. I don’t have all the details yet and promise to post them as soon as I have them.

RESTful Web APIs in Tokyo
I am very excited to announce that I will be attending a RESTful Meetup in Tokyo the evening of April 12. This was organized, in part, by a group of people who have also been hosting a bi-weekly reading group for the book RESTful Web APIs.

This group popped up last year to allow people to come together and translate the English-language edition of RESTful Web APIs in “real time” by taking turns reading the content and then discussing it as a group. Leonard Richardson and I are very grateful for this kind of enthusiasm and I am looking forward to meeting some of the people behind this cool project.

Singapore
I will arrive in Singapore on Monday, April 14 and don’t have any additional meetups scheduled yet. If you’re in Singapore and want to set up something, ping me and let’s see if we can get something going while I am in town for the public workshop on April 15.

Okay, Let’s Go!
The chance to visit customers, developers and designers in Seoul, Tokyo and Singapore really has me energized. If you’ve not yet signed up for one of the public workshops, please do. And come up and tell me “hello”. I’d love to hear about what you’re working on and how the API Academy can learn from your experience and help you reach your goals for building great applications for the Web and the enterprise.

(This post was originally published on my personal blog.)

April 3rd, 2014

Mobile Access Gateway 2.1 is Here!

Mobile Access GatewayLast week, we launched the Mobile Access Gateway 2.1 in style. The team has worked hard over the past few months to make sure the new features are coming together in a meaningful way. So, what’s in the new release?

First, we now allow customers to configure the usage of SiteMinder Session Cookies, with the Mobile SDK. In fact, the client libraries can use just about any token as the user token without breaking the existing model where we provision and manage token artifacts for users, apps and devices. With 2.1, you can use SiteMinder Session Cookies, SAML, JWT or any other user token. The Gateway administrator can configure what is relevant for the use case. As we know, there is a huge base of SiteMinder users who should now consider the Mobile Access Gateway as their mobility toolkit.

Second, the Mobile Access Gateway now supports social login for mobile apps. Social login support on the Gateway empowers developers to build apps that allow users to securely identify themselves by using sign-on credentials from social network platforms like Google Accounts, Salesforce, LinkedIn and Facebook. The social login flow is supported by the Gateway’s mobile Single Sign-On (SSO) capability. With mobile SSO and social login enabled, users login once with their social account credentials to access multiple enterprise and third-party applications from a mobile device. Additional contextual data such as geolocation can be combined with social login to provide a more secure API.

Third, with the 2.1 release, we now support Adobe PhoneGap. By leveraging the Cordova plugin interface, hybrid apps can tie in to the SSO and mutual SSL session negotiated by the native client libraries. This way, there is a unified security model for native and hybrid apps and app developers can choose to code application logic with their preferred tool chains.

Together with the existing Mobile Access Gateway features, this release provides app developers with better tools for writing awesome and secure mobile apps.

April 2nd, 2014

The Next Big Thing is Small

Written by
 

The Next Big Thing is SmallOne of the challenges facing the tech community is the addition of tens of billions of Internet-connected devices over the next few years. Currently, this Internet of Things (IoT) is expected to grow from 20 billion connected devices in 2015 to 40 billion in 2020.

That’s a Lot of Things
Estimates vary widely but most agree we have something less than 10 billion connected devices today including computers, handhelds, cars and controller devices such as SCADA and others. So, adding tens of billions more in just a few short years is definitely going to present some challenges.

A Lot of Little Things
And – if you start to think about wearables, RFID and micro/nano-size items, you realize that billions of these devices are going to be quite small. Not just physically but also in terms of capability and capacity. These devices will not have the power or flexibility of a laptop or even a handheld mobile phone.

These new members of the “connected community” will be tiny, single-purpose, low-power devices that do one thing and do it well. And it is likely that the program-ability of these devices will be limited. You might be able to flash the memory or even tweak configurations but a good number of these devices will not be hosts to custom code the way Web servers and handhelds are today.

Yet, we still need these devices to work together – even if only to publish device data, consume data from others devices and react to outside stimulus (lights on/off, heat, air movement etc.) So, how will we do that? How can we get things to interact with each other?

Step-by-Step Programming
Most developers today write “code” by stringing long lists of imperative statements together into a coherent set of instructions for machines. To most developers “programming” is just that – providing step-by-step instructions. This means we take on responsibility for any mishaps along the way, whether they occur due to problems inherent in the instruction set or due to unexpected events outside the instruction set, such as other devices not responding to our requests or sending us unexpected data. Doing this on tiny devices with limited capacity and ability is going to be a problem.

Luckily, there is another way to “program” these devices.

Rules, Not Code
We can also use a rule-based approach to programming. In this paradigm, programmers establish a set of coherent rules that tell the device how to respond to outside stimulus (“if the lights are on do X else do Y” or “if the motion detector reports true then turn on the light” etc.) And that is all you do; you write simple rules and leave the device to its own…. well, devices.

This means “programs” are much smaller (just a set of rules), easier to debug and easier to safely modify. It also means the devices themselves don’t need to do a great deal of work in order to “act” according to the rules.

That’s what I mean by small. The code will be small; the code will be rules.

How Does That Help Us with IoT?
It seems unlikely that we’ll be able to “program” billions of devices to safely and successfully interact with each other if we have to constantly provide step-by-step instructions on how each one operates and how they all interoperate. Instead, we’ll rely on simple devices each of which does one thing well and makes its action history available (as a stream of data, occasional dumps etc.) to other authorized devices.

It is also important to keep in mind that these devices will not be “phoning home” asking servers for guidance on how to proceed. The amount of traffic that tens of billions of new devices might generate if they need to constantly get instructions from distant servers would be massive and a huge waste of time and bandwidth. Instead, most IoT devices will act on their own, making decisions in real time, using the rules provided to them.

So, This is a Big Deal, Right?
This way of thinking about how devices will work and how we will “program” them is a big change for many developers. But not all of them: There are people today who build “low-level” device handlers and other things that do pretty much what I describe here. Motion detectors, security systems etc. all operate on this model (simple rules executed in real time). The difference we’ll see in the near future is that more of us will need to start designing and coding for devices that use this rule-based model.

But yes, this is a big deal.

By the way, I see quite a number of people building “Internet of Things” apps and models still assuming that the devices will be high-powered, fully-programmable computers similar to today’s handhelds and laptops. This is a mistake. While there may be some IoT devices with that profile, I suspect it will be a very small minority of the projected 40 billion devices.

So, start thinking ahead. Start planning for a new way to program devices. Those who start working like this now will have a jump on their peers and competitors. And there is good reason to start contemplating this right away. Rule-based systems will require different training and even different tooling. Think about how this will affect the “test-driven development” movement and related practices. And that’s just one example.

Are There Examples of This “New” Kind of Programming?
Yes, there are. And I’ll pick up that thread in a future post.

(This post, which was originally published on my personal blog, covers material from my recent talk at the API Strategy Conference in Amsterdam. You can see the notes from my talk online, along with the slides and related videos.)

March 27th, 2014

SDK vs API – Round 2

SDK vs APIInspired by a conversation with Kin Lane and Mike Amundsen at last year’s APIdays conference in Paris, I decided to dig deeper into the SDK-vs-API debate.

As I wrote in my last post, I had noticed a pattern of using API SDKs rather than the underlying Web APIs. Let’s quickly define what I mean by SDK. There used to be a time, not so long ago, when “SDK” meant documentation, code samples, build scripts and libraries all bundled together. Today, you find all the former on the Web and usually only the library remains. When I use the term SDK, I mean a programmatic API (e.g. JS, Ruby, PHP, Python) on top of the Web API (usually REST/JSON).

As it happens, my wife gave me a small wearable activity monitor as a Christmas present (I could not possibly think of any reason why I would need that – and the new weight scale in the bathroom must have been pure coincidence). Since the gadget was uploading my stats to a cloud service and this cloud service had an API and my wife gave it to me as a present, I figured I had a perfect excuse to do some coding. My goal was to write a client-side app using JavaScript, pulling my stats from the cloud service via the API (and to keep notes on my experiences).

After registering at the developer portal, I hit my first stumbling block – no client-side JavaScript SDK. The closest I could find was a PHP SDK – which, of course, meant that I had to install PHP (I had not used PHP before) and the framework(s) used by the SDK. I also had to enable a Web server and debug the SDK’s OAuth implementation. That was not quite what I had in mind. Even though I got it running after one day and a half, I ended up being quite frustrated. All that work for a simple Web page displaying the stats for a hardcoded day!

So, I decided to take a different approach and use the SDK provided by Temboo. Again, no client-side Javascript SDK. While I could have used a Node.js SDK instead, I decided to stick with my PHP install and opted for the PHP SDK. From there, the integration was quick and I was up and running within an hour. What I did not like about the SDK was the footprint (it included all possible integrations) and how its abstraction and data presentation leaked into my application code. If I were to build a commercial product using it, I would have to consider the potential stickiness of the SDK. Personally, this did not feel right either. So, I went back to the drawing board and looked at my options.

What had I learned so far? My frame of reference going into the experiment was a client-side app using JavaScript. Yet the only SDKs I had found were written for server-side integration. Since it was the only choice offered to me, I had to invest a significant amount of time finding all the necessary information to get the server-side components and dependencies installed and configured. But even after going through all of this, the experience with either form of SDK left something to be desired.

I had started this exercise thinking that using an SDK was much easier than coding against the Web API – maybe it was time to reassess that assumption.

Looking back at the API documentation, I could not find anything inherently difficult. Looking at the vendor-provided PHP SDK, it dawned on me that the complexity of the client was entirely due to OAuth and the use of XML as payload. This finally gave me the opening I had been looking for. If I could avoid the complexities of OAuth on the client and use JSON as the payload format, I should be able to implement my client-side app with a few lines of JavaScript against the Web API. As a regular guest at Webshell‘s APIdays conference, I was familiar with the company’s OAuth Broker service. It took me a few minutes to get set up, configure the service and download their oauth.js client library. I cut and pasted the sample code into a JavaScript file, consulted the API docs to learn about switching to JSON format and did the API call. I was done in less than five lines of code!

While this experiment is just a single data point, I think it nicely illustrates some of the key lessons in the SDK-vs-API debate. I will attempt to provide a summary from both the API consumer and the API provider perspectives in my next post. I will also be talking about the SDK-vs-API issue in more detail during the upcoming Nordic APIs tour in Stockholm and Copenhagen and at the APIdays conference in Berlin.

March 26th, 2014

Of Monsters & Men & Machines

Written by
Category API Security, IoT, M2M
 

Monsters Men Machines

In my last post, I talked about IoT and its nascent emergence into our everyday lives, with products like Anki Drive and the Nest Thermostat beginning to get a foothold. I also talked about the need for security, as IoT becomes more present in our day-to-day lives. Today, let’s talk about a few real-world examples where security was an “oh, we didn’t think of that” kinda thing.

Implantable medical devices (think pacemakers, for example) are absolute lifesavers for virtually all recipients. And, as you would suspect, they need to be monitored – usually at a doctor’s office. BUT what if the recipient lives in a rural area (e.g. anywhere in Montana, North/South Dakota, Wyoming)? A quick visit to the office might be out of the question. But there’s an app for that (you knew that was coming, right?) Pop an IP address and wireless on that pacemaker, plug that address into the doctors app and voila! Monitoring via the Internet! Yeah! Only thing is… suppose somebody got a hold of that IP address? And suppose that somebody had access to said app? Monitoring could easily become something far more nefarious – bumping up the heartbeat, slowing it down (either of which may have the same result, mind you). Not too cool.

Or how about using a baby monitor with video? New parents are always going to want to have complete unfettered access to their precious being – and the newest generation of baby monitors not only delivers audio but video and yes, with an IP address, there’s an app for that too! So mom/dad can be anywhere and keep complete tabs on the fruit of their loins. Of course, in the wrong hands, with an IP address and no security, that baby monitor all of a sudden becomes an audio/video surveillance tool. No big deal unless, say, that new mom or dad works in the President’s office, NORAD, banking or any one of a number of businesses where you really wouldn’t want to let sensitive information out via casual conversation around a dinner table – with the baby monitor catching every word.

Finally, how about the car – a ubiquitous item (in many countries) of which the newer ones are just chock-full of various computer systems, some of which talk to each other, some of which don’t, some of which are supposed to talk to each other but don’t (anyone played with the Cadillac CUE lately?). All these systems are there to make the driving experience either better or safer. One of these is simply brilliant – the Tire Pressure Monitoring System (TPMS) reports pressures to the primary automotive ECU, keeping the owner informed of poorly-inflated tires (when appropriate). By definition, these systems have to be wireless – and unfortunately, they are completely unsecured. What if someone was within range (say the car behind you) and used the same set of APIs that power the TPMS to send invalid data to the ECU – thereby potentially shutting down the car or, worse, making it unsafe?

All of these examples sound outlandish, right? And yeah, they are.

Oh and they’re also all true. The remarkable Robert Vamosi details these exploits, along with many others, in his phenomenal book When Gadgets Betray Us (available on Amazon here). Writing at a layperson’s level, Vamosi details time and time again how the emergence of IoT consistently takes security for granted or ignores it completely. It’s a scary bedtime story but worth reading. And it’s worth taking note of the key lesson: In IoT, security is very, very important.