Attend any Web API presentation and you are likely to see a graph like this one, demonstrating the growth of  publicly-available Web APIs. Speakers (including me) love using these graphs for good reason: they succinctly capture the explosive growth of APIs that has taken place over the last two years.

It’s a great story but it’s really only half the story. Web API experts regularly acknowledge the existence of a “private” or “closed” API market. In fact, many of us believe that if the number of private APIs in use could be cataloged it would dwarf the 7,000 or so APIs that are published on the ProgrammableWeb site.

As with many of the terms in the API world, there isn’t a concrete definition of  “private API”. In general, a private API has these characteristics:

1. It provides a language-independent interface that is made available via Web protocols.
2. It’s access is limited to a specific set of known developers or organizations.
3. It is not marketed to the general public nor is its documentation made publicly available.

Further to this, we can divide private APIs into three major buckets:

1. Internal APIs that exist within the organization’s borders (for example, SOAP-based interfaces within an internal Service Oriented Architecture).
2. Business-to-business (B2B) APIs that enable organizations to integrate with external companies.
3. Backend APIs that drive mobile, Web and device-based applications.

With this definition we can see that there are a great many integrations that must already exist. Enterprises have been building SOAP and B2B-based connectivity for years and have accumulated healthy inventories of private APIs.

In addition, the headlong rush towards the world of mobile is driving the creation of new externally-facing APIs to help corporations reach their customers. As I’ve talked about before, many organizations wish to retain control over the development of these applications and they can do this with private APIs.

If IT teams have been building these types of in-house connectivity solutions for so many years, there shouldn’t be much room left for innovation or improvement, right?

Not quite. Unlike those who build private APIs, public API designers are motivated by the need for their interfaces to be chosen out of the mass of APIs that are available to their prospective users.  This difference in motivation has created a massive impact on how public APIs are designed and managed. Architects responsible for private APIs have a great opportunity to learn from the public API world by adopting design strategies devised to drive adoption, in a controlled manner.

A good reason to take a developer-centered approach to private API design is the development cost associated with building applications that utilize the interface.  A well-designed private API can reduce the project costs for application development as well as for maintenance and upkeep of the integration.  Good design isn’t easy but it pays off – even when the audience is limited.

Many enterprises are implementing a “private for now and public later” API strategy.  It is a great idea but that doesn’t mean architects shouldn’t strive to incorporate great API design and a solid management solution.

In my next post, I’ll dive into private APIs in more detail and talk about some of the specific challenges that arise when building closed interfaces and how these challenges can be addressed with management solutions.

I’m excited to welcome back our API Evangelist Alex Gaber to do his second Tech Talk. Back by popular demand, Alex will take your questions on Optimizing Cloud-Driven Mobile Apps. Alex is a dynamic speaker who knows the app economy inside and out, has built several of his own mobile apps and regularly host hackathons all over the globe.

Building cloud- and API-driven mobile apps introduces complex challenges around syncing, caching and securing data. So, connect live with Layer 7 on Tuesday November 20, at 9am Pacific Time, when Alex will be answering your questions about how to address these challenges. Alex will also provide insight into a range of related best practices, including techniques for building cross-platform applications in HTML 5.

Click here to get the full event details and a reminder in your calendar. On the day of the event, join the event at layer7.com/live and tweet questions to #layer7live.

Sometimes design concepts are obvious. We know they are implicitly understood and don’t require drawn-out explanations. But sometimes these implicitly-understood concepts aren’t executed in real life because they haven’t been explicitly defined. I’ve come to the realization that designing APIs with the developer in mind is one of those ideas that often has an audience nodding their heads but which only a few take to heart and apply to their API architectures.

We in the API design world have a great opportunity to learn from our brethren in the product design world. The user-centered design approach for products has paid great dividends for those who can understand and apply the idea to their interfaces. The goal is almost stupid in simplicity – design products that your users will enjoy. But, as always, the challenge is in translating a simple concept into real strategies, methodologies and practices that do not lose that fundamental goal while staying applicable to unique marketplaces.

In our world of API design, most of us understand that machine-to-machine integration still involves a human – the developer who develops the client code. That developer – the one who makes or breaks us by deciding to use an API – is our user. While product designers talk about improving user experience, we talk about improving the developer experience.

But how does this actually happen? What do we specifically need to do in order to create APIs that are enjoyable to use? Indeed, what does enjoyable even mean in this context? This developer/API publisher relationship is a unique one and the product-based, user-centered design and human/computer interaction models cannot just be airlifted in. They need to be massaged and transformed so they are applicable to the Web API world, without losing the potential value inherent in a user-focused design.

I hope to explore these ideas over the coming months and come up with recommendations for how we can build API solutions that deliver on the promise of improved developer experience (or DX). I’ll dive deeper into the world of user-centered design and discuss methods for translating these concepts from the world of product design into our API design domain.

Recently, I’ve been working closely with a number of large enterprise clients who have already gone or will soon go live with Layer 7 solutions at the core of mission-critical infrastructure. I’ve observed that, in the API Management space, proof of concept and initial projects often focus on functional needs but the emphasis shifts to non-functional requirements as environments mature and sharing increases. There’s a clear, three-phase progression for large enterprises, which moves along these lines:

1. Solve the basic functional use cases – The 80% in the 80-20 rule
2. Solve the remaining, more complex use cases – The 20%
3. Deploy the basic functions on an enterprise scale – Back to the 80%

In Phase 3, it’s all about performance, scalability, operability, security, availability and consumability. The problems are very complex but the goal is to make the resulting solution as usable and simple as possible, given the wide range of users, developers, testers and operators that will be involved in its execution. As technology vendors, we are often guilty of focusing inwardly on bells and whistles, rather than outwardly on interoperability. This works well for phases 1 and 2 but brings a reckoning in the third phase. Fortunately, at Layer 7, we’ve spent the past decade working with enterprise clients and have evolved our products to meet their adaptability, reliability and automation needs.

The Layer 7 Management API is at the core of this capability. The Management API ships with all Layer 7 Gateways, to enable automated administration of policies, resources and access control that can plug into enterprise configuration management, deployment and monitoring systems. It can be accessed programmatically through a Java API, on the network through a Web service API or built into command line scripts. For the clients I have worked with, this capability and the assurance it provides on moving through the systems development lifecycle is quite simply a must have.

Despite how simple it is to support, compressing API traffic is an often-overlooked optimization. In situations where an API returns verbose resources, compressing the payload is a great way to reduce latencies. JSON and XML are highly compressible formats, for example.

APIs targeting mobile applications should pay special attention to improving call latency, as mobile apps are often used in bandwidth-constrained situations (e.g. using a mobile app on your smartphone connected to an airport wifi). One should set aggressive targets for these latencies, in order to maintain a positive user experience. Although UX specialists have many tricks up their sleeves, they can’t hide a 10-second API response time. Can your API always respond in 100ms or less under bad connections? Better?

Layer 7′s Gateways have built-in compression of REST API traffic using gzip compression. Most client-side frameworks also have built-in support for this kind of encoding. The compression is initiated by the requesting application, simply by adding the following HTTP header to its requests:

accept-encoding: gzip

iOS sample:
…
[urlReq setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"]
…

Android sample:
…
URL url = new URL(urlString);
HttpsURLConnection  conn =
(HttpsURLConnection)url.openConnection();
conn.setRequestProperty(“accept-encoding”, “gzip”);
…

JavaScript sample:
…
ajax=new XMLHttpRequest();
ajax.setRequestHeaders(‘accept-encoding’,'gzip’);
…

Any API traffic flowing through theLayer 7′s  SecureSpan API Proxy or SecureSpan Mobile Access Gateway automatically benefits from this compression.

Although the reduced-latency benefit of gzip encoding resources is more pronounced for larger resources and low-bandwidth networks, the compression tradeoff on the client side is negligible. API providers and mobile application developers should consider adopting this mode by default.

In addition to response compression, Layer 7 Gateways also support gzip encoding for request messages. This also provides reduction of latency on the client side when requests contain compressible payloads. For example, consider an HTTP PUT with content-type=application/json. The client application declares the compressed content using the content-encoding http header as part of the request.

PUT /aresource
Content-Type: application/json
Content-Encoding: gzip

[gzip encoded]{
‘a’: ‘large and complex json here’
}[gzip encoded]

When a Layer 7 Gateway detects that an API requester declares this “preemptive” compression, it will not only automatically decompress the request at the perimeter but also compress the response using the same mechanism by default (if the response has a payload).

200 OK
Content-Type: application/json
Content-Encoding: gzip

[compressed response]