Are we witnessing the beginning of the end of the application server? Today’s software development trends seem to point in that direction.
The traditional application server serves applications from the inside out. Developers develop Java apps based on classes housed in an app server. Then they are stuck with the API operations “helpfully” generated by the application server for each of the public methods of the application’s Java classes, regardless of how they actually wanted to design the API. To make matters worse, the APIs tend to be SOAP APIs, not using REST or JSON.
I’d like to propose an alternative “outside in” approach. In this approach, developers first design the API, which will be used to use their application. This is called “API First”; the API is the first part of the application to be designed. This is very different from having the API provided to you based on the structure of the Java classes used to implement the application. By adopting the API First mentality, organizations can reshape the traditional Web-server/application-server architecture by using lightweight client code combined with APIs and data sources hosted in public or private clouds. This API First model can deliver tremendous flexibility and lead to substantial cost savings over time.
Today’s trend toward mobile, social and the cloud is driving the emphasis on flexibility. It both requires and enables the API First approach. In this age of mobile and cloud computing, the API is how business is conducted. Mobile applications use REST and JSON mobile APIs to access enterprise data and services. Cloud-based services rely on APIs to integrate with on-premise applications and business processes. Business partners require APIs to exchange data and execute transactions. As developers today are increasingly aware, it’s much more straightforward to use a lightweight REST API if they want to deploy an application in a mobile device or in the cloud, or even in their own website. Frameworks such as Dojo make this choice simple.
Having an API delivery platform is central to the API First strategy. Mobile APIs are exposed to larger and more diverse populations of developers and applications. They consequently are exposed to higher levels of operational and security risks. To guarantee good availability and user experience, IT must have security, control and monitoring capabilities as part of its mobile API delivery platform.
The value of API First model is based on how easy it can be to run enterprise apps as mobile apps. For example, developers might want to be able to move internally developed applications into the cloud and to allow third-party developers to embed their functionality in different widgets—for example, Facebook apps. This requires the applications to be more “mashable” with other APIs. It is easier to design this type of mashability up front, rather than try to craft it onto APIs after the fact.
An API server allows developers to define their API first, and then map it to their back-end infrastructure, such as SAP or Oracle. In fact, the APIs do not have to map to actual REST APIs at the back end. Developers can create “virtual API operations” at the API server layer, depending on the type of client application that connects to it. For example, mobile apps get REST/JSON, and .NET apps get the same operation using SOAP/WSDL. As a result, the API server allows enterprises to save money and software developers to go beyond the Web-server and application-server infrastructure mindset.
The API First approach also can deliver substantial capital expenditure savings by cutting the costs of processor licensing. Application delivery can be done at the API server layer rather than by the app server. At the API server layer, for example, you can leverage caching and query processing, and as a result, you can offload processor-intensive activities from your app servers. As an added benefit, this not only will result in licensing fee savings, but it also will allow your IT team to focus on writing core application logic rather than writing code for infrastructure services to deliver the API.
We are now seeing examples of how API servers are allowing our customers to save money and to get beyond the current Web-server/application-server infrastructure mindset. For example, one of our customers is eager to move to a new enterprise-wide architecture consisting of lightweight client code, APIs deployed on the gateway, and data sources hosted in its private cloud.
The API First model also creates new business opportunities. Rather than engaging your own IT team to develop apps, you can leverage third-party app development. If you develop a really great API, then third parties can innovate on top of it and do things to add value that you didn’t think of yourself.
The API First model not only will allow you to reallocate your internal IT resources, but also manage so-called “freemium” offerings to make sure paying customers receive a higher level of service than non-paying ones. Its management and monitoring capabilities also will enable you to make sure your API is not abused and used as a channel to mine your valuable data.
The future of the API First approach to application development is indeed bright, but a final note of caution is in order. There’s always a danger that developers will be so swept up in today’s API economy that they will neglect the need for governance, risk management and compliance. While there are some differences between enterprise and consumer APIs, it would be a mistake to assume consumer APIs don’t need management, security and privacy controls because, around the world, GRC regulations have been enacted that strictly govern the management of personal information and protect personal privacy. All of this should be kept in mind when embarking on an “API First” strategy.
Mark O’Neill is cofounder and CTO of Vordel.
