First and foremost, an API can’t be considered private if it is open for widespread public use, right?  A simple way of keeping an API private is to host the interface on a public network without explicitly advertising or documenting its existence.  This can work well initially but may lead to problems in the future. If your service is valuable enough that others want to get their hands on it, even an undocumented, unsupported, private API can easily end up becoming a depended-upon API for application developers, resulting in an outcry when the API publisher has the audacity to modify or retire its own service.

A better approach is to provide access control at run-time and restrict usage of your API to a few known parties. There are a great number of methods for protecting access to internal resources but the best ones are those that achieve a balance between ease of implementation and resistance to infiltration. Security at all costs can greatly increase the complexity of an interface and – in turn – the time required to complete the projects that depend on it. Instead, we need to implement access control that is practical. Thankfully, security protocols like SSL, HTTP Basic authentication and OAuth 2 are great for providing the basic level of access control needed to make it difficult for outsiders to use a private API. Bear in mind that there is much more to API security than simply validating identity but this is the minimum level needed to ensure a degree of privacy.

Although a private API’s developers are generally known to the publisher, the best private APIs utilize API portal components to provide self-service registrations and integration to their private developer communities. This can greatly reduce the friction involved in getting API integration-based projects started and reduce the overall project costs for B2B and mobile-based initiatives. In fact, many of the lessons of simplified design, documentation and administration learned from the public API world can be directly applied to private API management. While the ultimate goal may be different (driving efficient API usage for private APIs rather than far-reaching adoption of open APIs), the ways of getting there are largely the same.

A unique characteristic of private APIs is the need to manage groups of developers. Unlike the public API space, private API publishers will often define out of band contract terms before offering up a quick self-service integration mechanism for that team. This type of group-based role definition is particularly common in integration projects that occur between organizations and can stretch the limits of API portal software that has been built primarily for open API use. Ideally, an API portal should at least be capable of managing developers within groups, communities or organizational affiliations as part of the self-service registration process. Even better, the portal could  provide capabilities for managing whole communities as separate domains within the same infrastructure.

Designing a private API certainly requires a different perspective but the good news is that much of the knowledge around public API design can be directly applied to interfaces you want to keep secret. Of course, building the management and security capabilities required to expose the API to your trusted parties can be daunting but that is why a great API management portal and gateway combination can save the day.

At the Layer 7 API Academy, we’ve had a few requests from API designers who are seeking strategies for handling large amounts of data in API responses.  Pagination is the most common method for addressing this scenario. Pagination, which is very common on the Web, allows API architects to conserve resources, improve response times and optimize the user experience. It’s a way of splitting up data into “pages” and is used in just about any API that returns collections of data.

I’ve released a short video tutorial titled Use Pagination in Web API Design to introduce the ins and outs of the interface. This video provides a crash course explaining pagination and outlining how to use it effectively in the design of Web APIs. I couldn’t fit all the implementation considerations I wanted in this six-minute tutorial, so watch out for a follow-up video on the subject.

That’s why we at the API Academy stress the importance of making rational decisions rather than irrationally selecting design patterns based on emotion or trends.  We want you to choose your design elements rather than picking them from the latest set of formats or technologies that you’ve heard about.

And that’s why we’re working on a series of tutorial videos, as my colleague Mike Amundsen recently announced. The first of these videos, titled The API Interaction Model – An Introduction, provides an overview of  a design process that will help you consider your user’s perspective in order to make effective design choices later. The ideas I discuss in this video are rooted in user-centered design processes that have been very effective in the software and product design worlds.

If you’re currently designing an API, invest five minutes and watch the video.  It should be time well spent.

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.

The reality is that many enterprises are already taking advantage of the API wave by using open API tools and philosophies to create and mange private APIs that, in turn, power their branded mobile and browser applications. This is a good thing as it allows businesses to reach their customers and to integrate easily with smaller mobile and device development shops. Plus, it fits well with a corporate culture of control. But organizations are missing a trick if they don’t consciously explore the benefits of opening these APIs up and joining the world of platforms, developers and communities that rely on open APIs to power their applications and projects.

These are big decisions with big consequences. The success of an enterprise open API program will likely be dependent on those at the very top of the organization providing the necessary leadership and investment required for big change to happen. That takes time. In the meantime, the projects won’t stop, the need for B2B integration will continue and the consumer demand for applications on every device will grow louder and louder. In this climate, there is an immediate need for enterprises to release APIs (be they private or public) as quickly and efficiently as possible while still addressing concerns over control.

Layer 7′s new APIfy service fits perfectly in this space as it allows small teams within the enterprise to get their private or public APIs out the door with a cloud-based API Management solution. They will get all the benefits of rate limiting, controlled access and the developer-friendly portal experience that are the hallmarks of a real Web API, in a SaaS platform. The fact that it is cloud-based means that smaller groups will be able to focus on delivering the solution without diving deep into hosting and implementation details.

Amidst all the decision making, strategizing and private API launches, the steady drum beat of progress towards open APIs in the enterprise has not stopped. The idea that information and services need to be shared in order to be valuable is taking root amongst thought leaders in the mainstream technology world and is, in turn, being heard within the enterprise. For example, Gartner has just published a research article claiming that financial institutions should be investing in APIs rather than applications (with API Management technology addressing the issues around control). Just as online banking started with private connections before it eventually landed on the public Web, the big banks could shift from private API adoption to public API adoption very quickly if the market demanded it. When banks open up their services for controlled consumption, there will be little doubt that the open API era has arrived for the enterprise.

It hasn’t gotten any easier to become an open API enterprise over the last three months but it certainly isn’t becoming less important. Hopefully, continued improvements in API Management technology will make that shift just a little bit easier.

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.

I was particularly impressed by the range of industries and organizations that were represented in the audience. We had developers from large enterprise shops, specialized Internet-focused start-ups and even a few entrepreneurs just getting started. I think this range of interest is indicative of the value of Web APIs for all and bodes well for a continued investment in designing great APIs, rather than just chucking them out into the ether.

Next up on the tour is our Paris API Workshop taking place tomorrow (Tuesday, October 16).  As always, we have a great set of speakers lined up, with Martin Duval from bluenove talking about building developer outreach programs and Benoit Herard from Orange Labs discussing their API launch. France has a  great start-up culture and a reputation for enterprises like Orange driving innovation, so I’m expecting good conversation, some excellent API Management presentations and – if I’m lucky – some great wines.

Over the last few years, we’ve seen explosive growth in open APIs across North America, lead of course by the avant garde Internet companies on the West Coast. The API Management industry has focused much of its attention on the US market but the Web API movement has definitely made its way to other markets and the push towards mobile and device-based applications is clearly having an influence on enterprise architectures.

Western Europe has had a strong influence on the API scene, with notable government and enterprise organizations diving wholeheartedly into the collaborative, developer-focused open API space. London, in particular, has developed a thriving technology scene with tons of hackathons, codeathons, meetups and start-up companies trying to change the world or at least get rich trying.

At the moment, the open API scene in India is still in its infancy and I’m looking forward to helping the concept blossom in whatever way that I can. As you may be aware, the number of mobile devices being used in India is mind-boggling and the ratio of mobile-use-to-desktop-computing is much higher than in North America or Western Europe.  This quantity of mobile client platforms, combined with the large number of motivated developers on the scene, makes this a very intriguing open API marketplace. I can’t disclose any details on the nature of the project yet… but I’m hoping to to have exciting news to share in the near future, so stay tuned.

I’ve spent most of the summer in North America, for a variety of reasons and I’m excited that I will finally be getting back home to the UK so I can re-engage with the European API and mobile scene. We have some great Layer 7 API workshops scheduled across Europe over the next few months and hopefully we will uncover a few new and noteworthy European API publishers while we are on tour.

The beauty the WebSocket protocol is that it lets an application seamlessly move from an HTTP/Web-based flow into a socket-based conversation and then back to a Web-based flow. In this way, it allows Web- and mobile-based applications to easily move from the traditional request-reply HTTP world into new forms of full-duplex, bi-directional communication.

We’ve seen a similar evolution in the past within the message-oriented middleware world. With the emergence of SOA and API, enterprises realized they needed new ways of moving data around and middleware technologies emerged that facilitated the movement of data in ways that were not possible with existing request-reply synchronous messaging infrastructures.

Traditionally, Web and mobile applications had to work hard in order to send or receive real-time data. Now, developers can use WebSocket to move data up and down the communication channel quickly and efficiently. This is like moving from an email client that requires you to constantly check for new mail to one that instantly alerts you when a new email arrives.

This style of communication will provide enormous benefits for applications that require messages to be passed quickly between the client and server.  Architects will have an easier time building applications with real-time messaging requirements, opening the door to some very intriguing solution designs.  Targeted notification systems, more-responsive UIs and even complex architectures such as massive grid networks built on top of the Web will be much easier to implement properly.

But, what’s missing from the WebSocket story is an effective way of minding the gates. The “black hat” guys already see WebSockets as representing a new attack surface, so organizations that are serious about providing reliable, scalable solutions will require some form of Gateway on the server side, to guard against security breaches.

To address WebSocket security, a Gateway must be able to enforce SSL handshakes, limit the number of connection requests, protect against payload injection attacks and enforce strong authentication methods – the same set of attack vectors that exist for SOAP/XML Web services and REST/JSON APIs.

That’s why I’m particularly excited about Layer 7′s recently-announced SecureSpan Mobile Access Gateway product. The Mobile Access Gateway extends Layer 7’s industry-leading technology for SOA and API in order to address mobile-specific concerns – and it includes a very secure WebSocket implementation.

In addition to the security benefits, the Gateway can be used to enrich or filter data in real-time. This opens the door to a new set of compelling use cases that includes data auditing, image watermarking and blacklist filtering – possibilities intriguing enough to stand on their own as justifications for implementing a WebSocket Gateway.

So, we’ve discussed what the WebSocket protocol is and why it’s so important to keep WebSockets secure. But how does all this fit into the exciting world of APIs that we’ve been focusing on in many of our recent blog posts? Our Principal API Architect Mike Admundsen will tackle this question next week, in our continuing series on this very important protocol.

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.