July 19th, 2012

Hypermedia APIs – Tech Talk Tuesday July 24 Featuring Mike Amundsen

Mike Amundsen Tech TalkOur recent Tech Talk discussing OpenID Connect was great. We had some pre-questions sent in via email, lots of live questions through the stream and some great questions through our twitter hashtag #Layer7Live.  We’re going to pick up on the momentum of that last Tech Talk and continue on with our next interactive API-focused discussion on July 24 at 9am PDT.

We’re very excited to be welcoming Mike Amundsen, Layer 7′s Principal API Architect, back to the Tech Talk studio. He’s ready to take on questions and discuss hypermedia APIs, a subject he literally wrote the book on.

  • What makes a hypermedia API different from other API types?
  • How is designing one different from designing any other form of API?
  • What are the benefits or complications for the publisher and the developer?

These are just a few of the questions that arise when thinking about designing hypermedia APIs. Now’s the time to get your thinking caps on and start formulating the questions you want to ask Mike on his specialist subject.

Make sure you click Add to Calendar to get the full event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:
»  livestream.com/layer7live
»  facebook.com/layer7

Submit your questions:

July 17th, 2012

Developer Management & the Layer 7 API Portal 2.1

Layer 7 API Portal Version 2.1As Layer 7’s CTO, Scott Morrison, recently stated: API Management = Developer Management. Okay, there are actually many elements to API Management – securing APIs, enforcing rate limits and SLAs, translating protocols and so forth. But if developers can’t make use of your APIs, then your APIs aren’t going to do you much good. So, providing a place where developers can discover, register for, learn about and leverage your APIs is – in many ways – the key to a truly effective API Management strategy.

That’s why the Layer 7 API Portal – which is designed to help organizations onboard, educate and manage developers – is one of the cornerstones of our API Management Suite.

The world of Web, mobile and cloud API publishing is growing and changing at an incredible rate right now, so we’re constantly working hard to expand and refine our line of API-focused products. With all that in mind – and hot on the heels of our SecureSpan Mobile Access Gateway – we’re very excited to announce version 2.1 of the Portal.

With the developer management needs of API publishers constantly evolving, we’ve added a range of new functionality to the Portal, including:

  • Advanced analytic reports
  • More granular privacy controls
  • Enhanced lifecycle management features
  • New customization options for the content management system

We’re exhibiting at Mobile+Web DevCon in San Francisco this week. If you’re at the show and you’d like to learn more about this new API Portal release, please stop by our booth.

July 13th, 2012

Layer 7 at Your Service

Layer 7 ServicesLayer 7 has been providing solutions for more than a decade. In this time, we have gained valuable experience of how to make our industry-leading products deliver maximum benefit in critical customer environments. In particular, we’ve gained a great deal of knowledge about how to translate clients’ business needs into robust solutions that meet the functional requirements and address key non-functional areas like performance, security and operations.

Recently, we’ve added a number of industry experts to our full-time team, in order to deepen this expertise and expand our delivery. Services have become an increasingly important part of our business and we have just launched a new Services section on our Web site in order to provide details of our service offerings.

Training Services are always the right starting point for new clients and we have a number of courses we can tailor to meet any customer’s needs. Following training, we can customize IT Services to provide consulting, configuration and any implementation activity. Our Business Services help companies explore new opportunities through technology. The current focus is on the many possibilities offered by APIs and we’re very excited to have noted industry experts Mike Amundsen and Ronnie Mitra leading this practice.

Please have a look at all the services we offer and let us know if any of these would help your company out. No matter what phase of a project you’re in, we will be happy to be at your service!

July 12th, 2012

Are Open APIs Too Open for Big Business?

Written by
 

Twitter and Facebook APIsI’ll admit it.. I’m a “big enterprise” guy.  I’ve either worked for or worked with very large enterprise organizations for most of my career and I’ve seen these companies struggle with the challenge of  incorporating ideas that are spawned from the collective brain trust of the theorists, coders and entrepreneurs that exist in the chaos outside the enterprise’s doors.

It took time and some adaptation for concepts like open source software, social media integration and viral marketing to become part of the enterprise world and I believe that opening up Web APIs will require a similar shift in mindset to work on the enterprise stage. The biggest ships take the longest to turn but modern businesses (even the most risk-averse) must be open to leveraging new technologies and architectural philosophies in order to avoid being left behind.

The buzz around Web APIs has definitely piqued the interest of big business and large enterprises have dipped their toes into its waters with the release of a few compelling APIs over the last year.  But, along with the excitement generated from opening new consumer channels and new avenues for innovation, there is still a  prevailing sense of danger associated with the API movement.

For many enterprises,  there is a fear that publishing APIs means giving up control of their services and data to an army of anonymous 16 year-old mobile developers. After all, who wants their carefully crafted brands and products to end up at the mercy of the masses? We’ve seen marketing experiments with “crowd sourcing” produce some interesting results in the past, so there is reason to be cautious when opening up the doors for collaboration in any form.

Of course, the good news is that the challenge of controlling APIs can be elegantly addressed with a strong API Management system. At Layer 7, our SecureSpan API Proxy gives enterprise customers the tools they need to maintain control over how content and services are used, allowing publishers to lock down APIs as much as they want.

However, publishers will also need to ensure that they provide enough accessibility to their API libraries or they will run the risk of exposing wonderful APIs that sit unused, waiting for developers to utilize them. APIs are only useful when they are used and a closed-door policy will not encourage anyone to sign up. That’s why we also offer the Layer API Portal, which is designed to facilitate developer community outreach and secure developer onboarding.

Making APIs attractive to the developer community is the key to increasing usage and it is becoming clear that developers want stability and control in the APIs they use. For example, Twitter’s continued restrictions on API usage and Facebook’s closure of the face.com face recognition API have created a small wave of backlash amongst their developer communities. While it’s not enough of a storm to make much of a dent in the uptake of Twitter or Facebook APIs,  application developers are realizing that building their apps based on APIs from which they may lose access is ultimately a losing proposition.

This is good news for larger enterprises as it signals a growing level of maturity in the API market and the need for stable, fairly-priced APIs that can support apps in the longer term. A set of well-designed, secure APIs with a well thought out revenue model is exactly the right fit for the large enterprise world.

So, are open APIs too open for enterprises? Probably. But enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace. Conversely, launching a poorly-designed API library just to get it out there can be an equally devastating misstep. Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.

It isn’t easy for enterprises to embrace open APIs but when the risks are managed properly with a well-built API Gateway, developer portal and API strategy, the rewards can be immense.

July 10th, 2012

Hey Twitter: API Management = Developer Management

Twitter APIQuick question for you: What matters most, the client or the server?

Answer: Neither —  they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame and a server without a client is simply unrealized potential. Bring them together though and you have something of lasting value. So, neither matters more and each actually matters a lot less than half.

In the API world, this is an easy point to miss. The server side always wields disproportionate power by virtue of controlling the API to its services and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something that is genuinely exciting), can be found a restatement of an early warning to developers:

“(D)evelopers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage its own API. Stifling competition by leveraging the API power card can only alienate developers — and by extension the public, who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green on ProgrammableWeb. Green acknowledged that API change is inevitable but pointed out that this is something that can be managed effectively — which is not what Twitter is doing right now.

The irony of the whole thing is that, in the past, by exercising its power position, Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace, this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API Management isn’t technical but social. Win the community over and they will move mountains. Piss them off and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy — and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Maintaining simplicity and a low barrier to entry counts for everything because it means you can get on with building real apps.

Now, I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community… Well, that is where the real work begins and — in the end — it’s all a lot less deterministic than we technologists like to admit. People are hard to manage but communities are even harder.

If there is a lesson here, it is that APIs are really about potential and that potential can only be realized when you have two sides — client and server — fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.