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

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.

January 31st, 2014

Would You Like a Library with That (API)?

LibraryIf you are professionally inclined – like I am – to read all about the business of APIs, you may have gotten the impression that APIs are going to take over everything and bring world peace.

Okay, I’m exaggerating but it is sometimes hard to remember that an API is really just a means to an end. That (business) end can vary. It might mean reaching more or different customers using mobile apps. It might mean integrating with partners. It might also mean giving access to services or data that provide enough value for them to be monetized. But in the end, I’m not using an API for the sake of using an API but because I want to use the services or data served by the API with the least amount of friction to myself because I – as a developer –  have a job to do.

Which brings me to my next point: When was the last time you looked at an API’s documentation and implemented it in a client app? If I need to integrate with an API in my Web app, I simply copy two lines of Javascript from the API provider page and cut and paste my API key into the <your_api_key_here> placeholder. Then I reload my Web app, which loads the Javascript library, which allows me to use the API. Or if I need to integrate with an API in the backend, I look for a pre-build component like a GEM (Ruby-on-Rails) or NPM (node.js) and add it to my loader file. Then I restart the backend, which loads the library, which allows me to use the API. Notice a pattern?

So here I am, using APIs via libraries/SDKs. In fact, I am not even sure when I last implemented a client using API documentation. In terms of priority, I only care if the service offered through the API meets my (business) needs – and then I use its library. And if it doesn’t have one, I might just move right along and look for the next one. (Remember: I have a job to do!)

For most developers out there in the real world, does consuming an API mean consuming an SDK that implements the API via a library? Should we talk about portable library design, efficient library loading (eager or lazy, async or sync) etc? Which platforms do I need to support to maximize my developer reach? What are the tradeoffs between offering (and having to support) a number of libraries versus just the API? Do dynamically-loaded libraries solve the API versioning challenge?

Reading about Evernote’s decision to use the Apache Thrift framework for its client API may help you formulate some potential answers to these questions.

In any case, none of this reduces the importance of providing a well-designed and documented API. Libraries and SDKs simply provide a convenient wrapper around an API and APIs are about removing friction. And client libraries are just another few steps in the march towards frictionless integration. (I still remember fondly the ease with which I was able to create client stubs and OSGI bundles from WSDL during the Web service days.) Nevertheless, we at Layer 7 – as an API Management company – will certainly be looking into how we can provide more support for client libraries in the future.

The preference for using client libraries rather than developing API clients becomes even more pronounced if we look at the Internet of Things.

Almost all the IoT integration vendors I have talked to consider supporting a large amount of client libraries for the myriad different IoT platforms to be one of their key differentiators in the market. Partly, this is driven by the need to optimize client stacks for resource-constrained platforms but it is also driven by the emergence of new binary and publish-subscribe protocols designed to better deal with IoT’s asynchronous communications patterns (see this blog post for a good overview).

While there has been quite some activity around API definition languages lately, I’m not aware of any attempt to provide a formal description language for asynchronous APIs of this type. Maybe this is an area where we will see some new ideas and innovation in the coming months.

In case you’re interested, I’ll be talking more about these trends as part of Layer 7’s upcoming API Academy Summits in London and New York.

January 30th, 2014

API Academy Summits

API Academy SummitsLast year, Mike Amundsen, Holger Reinhardt and I each traipsed around the world to bring API architecture guidance and advice to your home towns.  It was a lot of fun, we got to meet some great people and we had a chance to learn about the challenges that front-line API designers face. We also managed to earn a lot of air miles and give away a lot of t-shirts.

But this year, we wanted to top ourselves and do something bigger and bolder. So, instead of going out individually, Mike, Holger and I are getting together to dish out practical API design advice together in a series of API Academy Summits. I’m really excited about these events because we’ll have a chance to provide differing points of view and draw on our collective expertise to give you the best guidance possible. Our goal this year is to continue to go beyond the inspirational hype about why your business needs an API and go deeper, addressing the real challenges that people who actually have to implement API programs face in the real world.

In addition to the API Academy team, we are extremely pleased to have Forrester Research analyst Randy Heffner providing a keynote presentation. Randy has been a great source of API design information over the last year and if you’ve been reading his work, you’ll know he is all about providing great practical advice to API designers.

Our first Summit is taking place in London on February 6, closely followed by an event in New York city on February 13. These full-day events will include real API implementation stories from William Hill and L’Oreal as well as providing a mobile developer’s view of API design, courtesy of local London developer Niall Roche.

Last year, we were surprised to hear from API Academy workshop attendees that they wanted us to talk about Layer 7′s products. We want these to be vendor-neutral events but we’ve listened to the feedback and are trialing a short session introducing the Layer 7 API Gateway and Portal.  This session will be held at the end of the day and we promise not to lock the doors and force you to listen to the pitch!

So, if you have a chance to be in London on February 6 or New York on February 13, make sure you find time to join us for one of our API Academy Summits!

November 29th, 2013

Ending the IoT Protocol Wars

Ending the IoT Protocol WarsIt’s been a while since my last blog post – not least because I have been traveling quite a bit to run Layer 7’s European API workshops together with my colleague Ronnie Mitra. The workshops (part of Layer7′s outreach program via the apiacademy.co) are vendor-neutral and focused on sharing API design and management best practices.

To be honest, I probably learn as much during these workshops as the participants do. It has certainly been striking to watch how our material evolves throughout the workshops. We constantly keep adding and tweaking material, based on what we learn. In particular, I’m struck by the amount of changes my IoT section has been going through.

Here is what I have learned regarding IoT protocols: It’s a zoo out there, with lots of protocols trying to become the next HTTP. And some candidates deploy a formidable array of marketing, making it exceedingly hard to cut through the fog.

My current shortlist of main contenders is (in alphabetical order):

I might add STOMP to that list, just for its simple brilliance. STOMP is a text-based messaging protocol that has recently been extended to allow for binary content. Additionally, I’ve recently started talking with some transportation companies and learning about their use of DDS, which might be another candidate for the shortlist.

In the corner of residing champion, we have JSON/HTTP. Not content to see this protocol pushed into early retirement, advocates have been developing some very interesting approaches that attempt to ensure the continuing relevance of HTTP for asynchronous small messages – WebSocket being the most well-known. Hypercat, Simple Thing Protocol and EventedAPI represent just a small sample of the interesting approaches emerging to support async eventing and messaging with HTTP.

Where does this leave a developer trying to choose the right protocol for that awesome winged steam punk toaster? I don’t really have the answer but there are some documents trying to tease out the differences. Take a look at the MQTT vs. CoAP comparison from 1248.io or the DDS/AMQP/MQTT/JMS/REST comparison from DDS champion PrismTech.

Based on what I’ve learned so far, only XMPP and DDS have significant commercial deployments while MQTT is being evaluated by almost every major vendor I have talked to. While MQTT’s use as the protocol powering Facebook’s messenger is a good demonstration of its scalability, I don’t think this constitutes a proof point for mission-critical commercial deployments. If you know of commercial deployments of MQTT, I’d love to hear about them.

Each protocol has weaknesses: MQTT appears to be weak in security; DDS seems to be complex to scale and has version dependencies; XMPP is considered heavy-weight. But they all have strengths too, of course: DDS has the deployments in the field to prove its relevance; XMPP supports EXI and WebSocket for efficiency and a proven track record; both DDS and XMPP are extremely mature and have built-in security. Given the industry interest in MQTT, I am sure that whatever security problems exist will be fixed in one of the next versions. The one puzzling piece is the absence of CoAP in a commercial deployment. Again, if you know of one, please let me know.

Where do I stand on all of this? Having watched technologies rise and fall, I think it’s very normal at this stage to have multiple contenders trying to improve on HTTP. What I try to keep in mind though is that both bandwidth and computing power seem to be on an ever-increasing trajectory, while at the same time becoming cheaper and cheaper. Reduction in power consumption and increase in battery capacity, mostly driven through mobile, further lowers the bar for mainstream technology to power even small devices. I would not be surprised if, after the initial phase, we continue to see HTTP and JSON being dominant. As geeks, we sometimes get too excited about efficiency gains while losing sight of the fact that, for most products, technology simply needs to be good enough. But I won’t complain if I am proven wrong this time.

And don’t just take my word for any of this. To help you learn more, here are a couple of other articles reviewing IoT protocols: