The Oracle-Versus-Google Verdict Comes Down
June saw a remarkable amount of media coverage focusing on the world of APIs, as the Oracle/Google court case made headlines. Layer 7’s Jaime Ryan was relieved that the ruling stated APIs are not protected by copyright. Jaime said: “By taking a strong stand on the issue… the judge has possibly prevented a whole new round of lawsuits that could have rivaled the still-ongoing Apple/Samsung/Google patent wars.”
Read the full post >>>

Are Open APIs Too Open for Big Business?
In July, Ronnie Mitra took a detailed look at how nervous major social media platforms like Twitter and Facebook were becoming about their open APIs and concluded that “enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace… Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.”
Read the full post >>>

Why I Still Like OAuth
In the midst the controversy surrounding July’s formalization of OAuth 2.0, Scott Morrison launched a passionate, though qualified, defense of the standard. Scott argued that “sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy. But it’s needed and it’s needed now, so let’s all forget the personality politics and just get it done.”
Read the full post >>>

History Repeats: The Search for Agility & Reuse Through APIs
This September, Dimitri Sirota visited the SDP Global Summit in Rome and noticed how much of the discussion around telecom carriers’ API initiatives echoed the SOA talk of a decade ago. He noted “telco after telco (echoed) the decade-old SOA mantra of abstraction, agility and reuse when talking about their new API initiatives… But if Web APIs are to deliver on the SOA vision of agility and reuse, they will need some of the same plumbing that made Web services work.”
Read the full post >>>

RESTful or Not?
Also in September, Mike Amundsen provided an explanation of the key term “RESTful”, which is so often used in reference to APIs and Web services. Mike explained: “Essentially, REST… is a style. Specifically, it’s a style of network-based software architecture. This style was first defined in 2000 by Roy Fielding. Fielding stated that ‘an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference’.”
Read the full post >>>

Essentially, REST (representational state transfer) is a style. Specifically, it’s a style of network-based software architecture. This style was first defined in 2000 by Roy Fielding. Fielding stated that “an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference”.

The set of architectural constraints Fielding defined in his dissertation remain the key criteria by which we judge whether or not a service is RESTful. Back in 2000, Fielding did a very good job of defining the six primary constraints: client-server; stateless; cache; uniform interface; layered system; code-on-demand.

However, REST is also defined by four “interface constraints” that are only partially defined in the dissertation: identification of resources; manipulation of resources through representations; self-descriptive messages; hypermedia as the engine of application state. In particular, the definitions of self-descriptive messages and hypermedia are still debated.

Assuming you can decide on clear definitions of all 10 constraints, all that remains is to identify each of them within the target design. If the implementation does not exhibit all ten (well nine, since code-on-demand is optional), then it is not RESTful. This last step is not difficult. It is the previous step (agreeing on definitions) that causes problems.

Still not sure if your service is RESTful? Well, I originally published this post, in expanded form, on my personal blog. If you want to dig deeper, take a look over there.

This may sound like a typical tech conference but REST Fest is hardly that. Taking its cue from OpenSpaces and similar events, REST Fest is organized by attendees, for attendees. For example, one of the days is devoted to everyone hacking on the same general topic. Another is dedicated to short workshops, all presented by selected registrants.

Similarly, all the general session talks are delivered by the attendees themselves. That’s because one of the “rules” of REST Fest is “everyone talks and everyone listens”. When you sign up to join REST Fest, you are expected to deliver at least a five-minute lightning talk – and there are no exceptions!

Notable presenters will include keynote speaker Stu Charlton (former CTO of Elastra), Matt Bishop (Senior Product Architect at Elastic Path), Pat Cappelaere (currently working on NASA’s SensorWeb project), Leonard Richardson (co-author of O’Reilly’s RESTful Web Services), Sam Ramji (Head of Strategy at Apigee) and yours truly.

I feel privileged to be co-chair of REST Fest and I’m pleased to note that Layer 7 is the event’s Head Sponsor this year. Hope to see you there!

OpenID Connect is an emerging standard that adds federated authentication to OAuth 2.0-enabled systems. It’s a suite of lightweight specifications that provide a framework for identity interactions via RESTful APIs. And in its simplest deployment, OpenID Connect allows all types of clients including browser-based, mobile and javascript to request and receive information about identities and currently authenticated sessions.

So, it’s a relatively simple protocol that helps make authenticating complicated scenarios easier. And let’s be honest – simple and easy are always welcome when it comes to securing RESTful APIs. Authorization and authentication are now available using only one technology. This makes life easier for anyone looking to secure their APIs.

But of course, questions always arise when discussing the various implementation scenarios for OpenID Connect. That’s why we’re excited to welcome Senior Software Developer Sascha Preibisch as our special guest for our July 10 Tech Talk Tuesday. He will answer any OpenID Connect questions you may have – so get those questions ready and join us on July 10 at 9am PDT.

Here’s how to join the discussion:

Click here to get a reminder in your calendar.

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

Tuesday, July 10 | 9am PDT | 12pm EDT | 5pm BST

Submit your questions:
Tweet using the tag #Layer7Live
Email techtalk@layer7.com
Check in & Chat through Facebook

APIs are popping up everywhere and creating amazing integration possibilities. One of the coolest demos I saw at Gluecon was Ducksboard’s dashboard service, which lets you create your own monitoring dashboard using a library of widgets for existing social and Cloud providers. You can even create your own widget and have your own data pushed to it via an API endpoint created just for you, on the fly – so sexy!

Thanks to everybody who came to my presentation Making Sense of API Access Control. I hope this shed some light on how to leverage OAuth for controlling access to REST-based APIs. A lot of the new APIs I discovered this week could certainly use some help in that regard. API key authentication in HTTP basic without password has its limitations. The slides from Making Sense of API Access Control are embedded below.

At Layer 7, our enterprise customers build incredibly elegant API platforms using our API management technology. Our solutions recognize that one size does not fit all and we provide the tools to adapt to changing requirements without re-architecting new APIs from scratch. Though we certainly support the simple “large number of known and unknown developers” use case Jacobson describes – with robust, scalable technology deployed on a wide variety of hardware, virtual, software and Cloud platforms – we can also address the specific concerns raised by the variety of devices and environments in Netflix’s ecosystem.

Message size, structure and delivery constraints due to device variation represent a large part of the problem. Layer 7 Gateways support the relevant formats and transports and can perform message transformation and protocol mediation on the fly. Policy-based configuration enables custom “virtual” APIs tailored to each device, community of developers or calling application. These format and behavioral changes can be explicit or can be triggered by user identity, app permissions, message content or transaction metadata. Even more complex mediations, such as REST exposure of internal SOAP-based assets, are simple to configure and help to reduce re-implementation costs.

Interaction models can also be optimized and tailored to the calling platform. Composition of comprehensive document-based APIs from multiple backend calls can reduce chatty client interactions. Conversely, small messages from memory-constrained devices can be aggregated into larger, less frequent backend calls. Mobile traffic can be optimized using persistent HTTP(S) connections and over-the-wire compression. And content can be cached at any level of granularity, using an in-memory cache like Terracotta, to reduce the number of calls to the application backend.

As director of one of the world’s most broadly adopted public APIs, Jacobson’s most profound observation is that “public APIs are waning in popularity and business opportunity and… the internal use case is the wave of the future.” API infrastructure needs to support everyone – open API developers, internal coders, contracted development teams and partner groups – especially as mobile workforce enablement and BYOD gain popularity. Layer 7 solutions allow enterprises to make that distinction clear through public vs. private APIs, configurable classes of service and role-based access control.

Jacobson mentions several piecemeal solutions that he and others have attempted to compile into a working platform but notes that those approaches still fall short. Providing an enterprise-grade REST API is no simple feat and it’s great that the truth of the matter is starting to come out. The benefits of a successful API strategy are numerous and well-documented. Layer 7 is the only vendor providing an API management solution that incorporates all the basic necessary functionality and much, much more.

First of all, in the three-tier architecture of the Web, the line was typically blurry between the presentation and logic tiers and concrete between logic and data. Big data now blurs the line between logic and data. Combine this with the fact that the mobile app development paradigm fragments the presentation platform and it is evident that the API will become the concrete and consistent border in application processing flows. In this context, API management will prove vital in enforcing security, collecting business metrics and normalizing protocols.

Second, big data allows analytics to be performed in the scope of real-time data retrieval. This will create another wave of real-time integration needs in enterprises of every size. More real-time integration means more APIs with higher volumes. The common protocol for exposing big data on the network is REST using either JSON or XML formats. Again, this will mean a greater necessity for API management tools and techniques and a compound benefit in their usage.

Simply put, mobile, Cloud and big data are driving a new era of enterprise IT and API management will provide amplified value for companies embracing these trends.

We’ve previously provided some insight into the process of translating between REST and SOAP in a tutorial on our Web site. In that tutorial, we demonstrated how our policy language lends itself to a simple way of defining the conversion process, making converting REST to SOAP a fairly trivial exercise. However, if you have tens or hundreds of existing SOAP services, translating them all to REST might seem somewhat daunting.

Luckily, a Layer 7 Gateway can also help to make that process considerably easier – and I’m going to show you how. I’ll be walking you through a wizard that makes it simple to (a) upload your Web services to the Gateway as WSDLs and then (b) customize how you want the REST version of each service to look.

First, you upload your WSDL.

Then, configure how you would like to present your REST interface.

Each operation can be customized with the type of HTTP method used.

Once you submit your configuration, you’re ready to go!

At the end of the wizard, sample HTML-based documentation is provided that can be used for presenting the REST endpoint to your clients. This documentation is the first step in presenting the details of your new RESTful API via the Layer 7 API Portal.

Here’s an example of the same operation above that was converted to a HTTP GET style.

Finally, we also provide a sample WADL based on the parameters that you specify.

Once you login to the Layer7 Policy Manager, you’ll find a predefined policy that does all the conversion from REST to SOAP.

From here, you can add any additional policy enforcement requirements as you see fit.

And now it’s time for the next episode. We’re excited to announce that Scott Morrison, our CTO, will be the guest expert and he’ll be taking questions on how you can simplify REST adaptation using existing IT infrastructure. So save the date – on Tuesday April 3, we’ll be streaming live at 9am PST. Start thinking of some great questions to ask Scott and be sure to tell your colleagues about this rare opportunity to chat live with Layer 7′s CTO.

To join the session, simply go to the Layer 7 Facebook page and click the Livestream icon. Once the Livestream app is open, click the play button and you’ll be watching the stream live. If you want to ask a question, click the big red button that says “check in and chat” and bang you’ll be ready to chat live with Layer 7. We’re really excited about this talk and anticipate lots of audience engagement. So we’ll see you next Tuesday April 3, live on Facebook.

The Enterprise is buzzing with API initiatives these days. APIs not only serve mobile applications, they are increasingly redefining how the enterprise does B2B and integration in general. API management as a category follows different models. On one hand, certain technology vendors offer specialized infrastructure to handle the many aspects of API management. On the other, an increasing number of SaaS vendors offer a service which you subscribe to, providing a pre-installed, hosted, basic API management system. Hybrid models are emerging but that’s a topic for a future post.

Before opting for a pure SaaS-based API management solution, think about these key considerations:

The Cloud Advantage
One can realize the benefits of Cloud computing from an API management solution without losing the ability to control its underlying infrastructure. For example, IaaS solutions let you host your own API management infrastructure. Private Clouds are also ideal for hosting API management infrastructure and provide the added benefit of running "closer" to key enterprise IT assets. Through any of these SaaS alternatives, an API management infrastructure optimizes computing resource utilization. IaaS and private Cloud-based API management infrastructure also provide elasticity and can scale on demand. Look for an API management solution that offers a virtual appliance form factor to maximize the benefits of Cloud.

Return on Investment
The advantage of a lower initial investment from SaaS-delivered API management solutions quickly becomes irrelevant when the ongoing cost of a per-hit billing structure increases exponentially. With your own API management infrastructure in place, you can leverage an initial investment over as many APIs as you want to deliver, no matter how popular the APIs become. Many early adopters, which originally opted for the SaaS model, are currently making the switch to the infrastructure model in order to remedy a monthly cost that has grown to unmanageable levels. Unfortunately, such transitions are sometimes costing more than any initial costs savings.

Agility, Integration
SaaS solutions provide easy-to-use systems isolated in their own silos. This isolation from the rest of your enterprise IT assets creates a challenge when you attempt to integrate the API management solution with other key systems. Do you have an existing Web portal? How about existing identity, business intelligence or billing systems? If your API management solution is infrastructure-based, you have access to all the low-level controls and tooling that are required to integrate these systems together. Integrating your API management with existing identity infrastructure can be important to achieving runtime access control. Integrating with billing systems is crucial to monetizing your APIs. Feeding metrics from an API management infrastructure into an existing BI infrastructure provides better visibility.

Security
Depending on the audience for your APIs, various regulations and security standards may apply. Sensitive information traveling through a SaaS-based system is outside your control. Are any of your APIs potentially dealing with cardholder information? Does PCI-DSS certification matter? If so, a SaaS-based API management solution is likely to be problematic. In addition to the off-premise security issue, SaaS-based API management solutions offer limited security and access control options. For example, the ability to decide which versions of OAuth you choose to implement matters if you need to cater to a specific breed of developers.

Performance
Detours increase latency. By routing API traffic through a hosted system before it gets to the source of the data, you introduce detours. By contrast, if you architect an API management infrastructure in such a way that runtime controls happen in the direct path of transaction, you minimize latencies. For example, using the infrastructure approach, you can deploy everything in a DMZ. Also, by owning the infrastructure, you have complete control over the computing resources allocated to it.

I'll be touching upon some of these issues when I give a presentation called Enterprise Access Control Patterns for REST & Web APIs on March 2, at the RSA Conference in San Francisco.