May 21st, 2014

The Increasing Impact of APIs on the Digital Marketplace

Written by
 

The Increasing Impact of APIs on the Digital MarketplaceFor years, organizations connected distributed applications using increasingly complex protocols. But as the principles of the World Wide Web rapidly penetrated the business world, IT organizations began to realize that many of the concepts, infrastructures and protocols that enable the infinite scalability of the Web could be applied to enterprise application development. Enter the application programming interface (API).

Business needs are driving enterprises to open their data and applications more to partners, developers, mobile apps and cloud services. APIs provide a standardized way to open up information assets across the Web, mobile devices and the cloud. However, to make API information sharing safe, reliable and cost-effective, enterprises must deal with critical security, performance management and data adaptation challenges.

The API can be used as a lingua franca of modern computing, allowing the enterprise to selectively open up applications in order to create value. It is not a coincidence that the API movement has grown in importance as a new generation of coders has come of age – a generation that values simplicity and getting the job done.

The complexities valued by the previous generation of developers are giving way to developers more focused on lowering the barriers to entry and on improving the accessibility of information while ensuring the security of critical enterprise resources. APIs allow developers to greatly simplify integration.

APIs open up new opportunities for executives to evaluate business information resources in order to build value for the enterprise by creating services that others can consume. For example, the New York City Subway System opened up APIs so that developers could build apps exposing train status information. The Metro Transit Authority (MTA) recognized that its core business was transportation, not app development, so it didn’t try to build smartphone apps but instead exposed its core information systems through APIs that allow developers to create apps which provide consumers with updated transit information.

The MTA is leveraging information in existing systems in order to allow developers to build apps that create more informed consumers, who are presumably becoming more reliant on public transportation. This strategy is allowing the New York MTA to provide better transportation through APIs and cities like Washington DC are similarly opening up their APIs to make transportation easier for their citizens. By understanding consumer needs for better and timelier transportation information and filling those needs by opening up APIs to the development community, transportation providers are building more loyal customers.

Understanding the opportunities to capitalize on APIs is crucial and many companies are turning to their marketing departments for direction on API strategies. To their credit, marketing professionals are often forward-looking and trend-driven and many have been monitoring API advances and seeing the business opportunities potentially enabled by API adoption. They are well positioned to evaluate available data within business applications in order to determine what information the organization should make available in a safe and secure manner to create value for the enterprise.

Once the APIs are developed, the ability to promote available APIs among the development community is essential for gaining acceptance and adoption. Organizations need the ability to market their APIs to create interest within the development community. To obtain maximum value from APIs, enterprises need ways to attract, onboard and manage developers.

The CA Layer 7 API Management Suite provides enterprises with a comprehensive set of solutions that externalize APIs in a secure, reliable and manageable way. It includes the CA Layer 7 API Portal, which allows the enterprise to deploy the infrastructure to monetize APIs, advertise them and create communities around them. This allows organizations to capitalize on the increasing impact APIs are having on the digital marketplace and to build and manage secure APIs that create increased value for the enterprise.

May 9th, 2014

Trade Shows, Connected Cars & Secure APIs

API Events May-June 2014May and June are shaping up to be busy months here at Layer 7! We will be sponsoring and exhibiting at a number of leading industry events and our API Management experts will be speaking at several of these shows.

Notably, throughout the month of June, our speakers will be focusing on the “connected car” – a prominent Internet of Things use case. Below, I’ve provided a list of some upcoming shows that will have a Layer 7 presence. If you’re attending any of these events, take the opportunity to learn how secure APIs will be vital to enabling automotive connectivity. And be sure to stop by the Layer 7 booth to say “hi”!

For full details of our upcoming events, visit the Layer 7 Web site. And if you’d like to schedule a meeting with one of our experts at any of these shows, please reach out to us by emailing events@layer7.com.

Layer 7 events in May/June 2014:

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.