April 17th, 2014

Next API Tech Talk: Linked APIs

Linked APIsThe challenges faced by today’s software architects go far beyond the familiar. “Big Data” means more than managing petabytes of data – it requires dealing with data-sets that span organizational boundaries. Likewise, the term “distributed system” no longer refers to just a multi-tier architecture or cloud deployment – it usually involves the connection of non-heterogeneous systems across multiple organizations.

On Thursday April 24, I’ll discuss these challenges as part of Layer 7’s latest API Tech Talk. I’ll be using this opportunity to explore how architects can leverage “linked APIs” to handle Big Data sets and distributed systems that cross organizational, technological and cultural boundaries, breaking through data silos in order to better integrate information. Interested? Just add the Tech Talk to your calendar and go to api.co/L7live at 9am PDT (12pm EDT) next Thursday.

I’ll also be taking your questions on linked APIs, Big Data, distributed systems, open source and anything related, so please don’t hesitate to join in. You can submit your questions now by email or you can chat with me or tweet them at me on the day. This will be my first Tech Talk since joining the Layer 7 API Academy and I’m really, really looking forward to a lively discussion. See you on April 24!

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

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 10th, 2014

The Internet of Things – Today

Anki Drive CarA quick intro: I’m Bill Oakes, I work in product marketing for CA Layer 7 and I was recently elected to write a regular blog about the business of APIs. I’ve been around the block over the years – a coder, an engineer… I even wrote a BBS once upon a time (yes, I’m pre-Web, truly a dinosaur – roar!) But now I “market things”. That said, I still have a bit of geek left in me and with that in mind, this blog is going to focus not so much on the “what” or “how” when it comes to APIs, their implementations and how they affect businesses/consumers but rather, the “why” (which means, alas, I won’t be writing about the solar-powered bikini or the Zune anytime soon – I mean, really… why?)

For an initial first post, I thought I’d take a look at the Internet of Things (IoT) because it’s something no one else is really discussing today (cough). We are beginning to see the actual emergence of nascent technology that can be called the IoT. First, I’m going to take a look at one particular example – one that’s actually pretty representative of the (very near) future of IoT. Yes, I’m talking about Anki Drive (and if you haven’t heard of Anki Drive, you really should watch this short video).

What’s amazing about Anki Drive cars is that they know WHAT they are, WHAT their configuration is, WHERE they are, WHERE you are… Five hundred times a second (in other words, effectively real time), each of these toy cars uses multiple sensors to sample this information using Bluetooth Low Energy, determining thousands of actions each second. Oh… and they’re armed!

Equally amazing is the fact that kids of all ages “get it”. (By “kids”, I of course mean “males” – as once males hit 15 or so, they mentally stop growing, at least according to my wife. Although, I’ve seen many women enjoy destroying other vehicles with Anki too… but I digress.) Players intuitively know how to use the iOS device to control their cars and after learning the hard way that the “leader” in this race really equates to the “target”, they adapt quickly to compete against true artificial intelligence (AI) and each other. It really is an incredible piece of work and is absolutely the best representation of the IoT today.

So, you ask: “What does this have to do with moi”? Well, imagine if your car could do this kind of computation in real time as you went to work. Certainly, Google is working aggressively on this track but Anki lets you get a feel for it today. (And I’m fairly certain Google is not going to provide weaponry its version.) Still, the real-world application of this technology is still a ways away. Let’s reign in timeframes and take a look at what is happening with the IoT in other industries today.

Imagine that your appliances knew about and could talk to each other. Google, though its Nest acquisition, is working on this with its learning thermostat. My first thought on the Nest was something along the lines of: “What kind of idiot would spend $250 on a thermostat when you can get a darned good programmable one for around $50?” But then Nest introduced the Protect. Simply an (expensive) smoke detector with CO detection built in. Big deal, right? Except that if your Nest Protect detects CO, it makes a somewhat logical assumption your furnace is malfunctioning and sends a command to the thermostat to shut down said furnace. That is the power of the IoT in the real world today. So I bought into Nest (thus answering that previous question) and, yeah, it’s pretty cool – not nearly as cool as Anki Drive but then Anki really doesn’t care if my furnace has blown up and Nest does.

As we see more and more real-world introduction of functional, useful IoT solutions, these solutions will all have one thing in common: they will use APIs to communicate. And what IoT will absolutely require is a solution that ensures that only the right devices can communicate with other right devices, in the right way, returning the right results, with no fear of Web-based (or, technically, IoT-based) threats, bad guys, MITM etc. As solutions roll out, it’ll be interesting to see how many vendors remember that security and performance are not options in IoT – they are 100% essential.

February 21st, 2014

RSA Conference 2014 Preview & a Special CA Layer 7 Event

RSA Conference 2014Despite all our advances in communications — from social networking, to blogs, to actually functional video meetings — the trade conference is still a necessity. Maybe not as much for the content, which makes the rounds pretty fast regardless of whether you attend the show or not, but for the serendipitous meetings and social networking (in the pre-Facebook/Twitter sense).

I find something comforting in the rhythm and structure a handful of annual conferences bring to my life. The best ones stay rooted in one location, occurring at the same time, year after year. They are as much defined by time and place as topic.

If it’s February, it must be San Francisco and the RSA conference. I’ve attended for years and despite the draw from the simultaneous Mobile World Congress in Barcelona, RSA is a show I won’t skip. But I do wish MWC would bump itself a week in either direction so I could do both.

As everyone knows, this year the press made much ado of a few high-profile boycotts of the conference and the two alt-cons, Security B-Sides and TrustyCon, that sprung up in response. But I think it’s important to separate RSA the company from RSA the conference. The latter remains the most important security event of the year.

Every year, one theme rises above the rest. I’m not referring to the “official” theme but the trends that appear spontaneously in the valley. The theme this year should be security analytics. The venture community has put this idea on an aggressive regime of funding injections. We should expect an entertaining gallery of results, both good and bad. But either way, we will learn something and it would be a poor move to bet against this sector’s future.

I’m also expecting 2014 to bring some real SDN traction. Traditional security infrastructure is low-hanging fruit vendors too often miss. RSA is where SDNs for security will finally get a long-awaited debut.

MWC may be the premier event for mobile but most mobile security companies cover both conferences and CA is no exception. At RSA, we’ll be unveiling the new version of our Mobile Access Gateway. This features SDKs for iOS, Android and JavaScript that make enterprise authentication simple for mobile developers.  As a bonus, these SDKs offer cross-app SSO. This means users sign on just once, from any authorized app. You should definitely come by the CA Technologies booth at either show to have a look. And if you do see me at the RSA show, be sure to ask me about the integrated PKI — surely one of the coolest, unsung features underneath the SDK hood.

CA and Layer 7 will also be hosting an afternoon event on Monday Feb 24 at the nearby Marriott Marquis and you are invited. You may recall we’ve held a few of these before but this year, we have a very special guest. The event will feature Forrester analyst Eve Maler, who will talk about zero trust and APIs. It will be a great way to kick off RSA 2014 and we’ll even give you a nice lunch. Who could refuse that?

To join us, sign up here.