When we look at new products coming to market, especially products coming from startups we can notice a change in relation to how more traditional applications are build. One of the main differentiators is that almost all startups that have become a success provide the development community with the option to connect to the solution via API’s. Visibly in social media platforms and consumer focused platforms you can see that API’s are a key differentiator for success and will increase the adoption of the platform or software solution. However, not only in the consumer focused B2C market we can notice this trend, also in enterprise applications we see a growing rate of products and platforms that by default provide an API to interact with.
The growing number of products and platforms that provide customers with the option to interact via an API has a very good reason. It allows customers to embed the product in an end-to-end process and use the functionality in more ways than the original developer could have imagined. It also provides the original developer the option to point to the availability of the API’s in case a customer would like to have more functionality.
Due to the fact that customers have the option to interact with solutions via API’s and “embed” them in other products will raise the adoption of a new product significantly, will make selling the product more easy and will ensure the product is more easily embedded in an overall enterprise Architecture.
With this knowledge it is important to understand that when you develop your own product, potentially to be used externally or purely internally, you can raise the adoption within your enterprise architecture by ensuring your product is equipped with API’s. Traditionally when developing an enterprise grade solution it was common to think only about functionality that would live within the borders of the application itself and in some cases extended with the option to import and export file based information. With a changing architecture paradigm to more API based solutions you will have to ensure that your application is able to communicate with other modern, API enabled, applications.
When thinking about what your API’s should be able to do it is important to understand that you will not understand the extent to which they could be used. When thinking about what your API’s should be able to do you should try to ensure the customer can request information and request system functionality in the most wide sense of the word while keeping the integrity and security of your application in mind.
By exposing your application or business service via an API you will be able to make it part of a growing layer of services to which can be connected in a service oriented architecture fashion. This can be done via connecting to several API’s or webservices by making use of an enterprise service bus, or other applications can directly communicate with the API’s where this is more appropriate.
When developing and operating solutions that do have API’s and you do have an Oracle centric enterprise IT landscape it is advisable to take a look at a number of products that Oracle provide. You will have to look at Oracle Enterprise Manager for overall monitoring and management, however more specifically for API’s oracle has two other interesting products.
Oracle API management
Oracle provides a complete API Management solution that ensures success with exposing APIs both within and outside your organization. It provides role focused user interfaces, complies with standards, and delivers on business value. The following steps outline how to get started with API Management, as soon as specific functionality is identified that needs to be exposed in your applications.
Publish and Secure APIs with Oracle API Gateway Oracle API Gateway acts as a control point for managing how internal users and application assets are exposed and reduces security risks. It allows enterprises to leverage their existing Identity and Access Management investments by extending authentication authorization and risk policies to mobile, cloud and enterprise applications – without changing backend applications. It helps manage APIs (support for OAuth, REST API security and JSON) and centrally protect and manage API Authentication Keys.
Manage API Lifecycle with Oracle Enterprise Repository Support API lifecycle management with governance controls and automation from planning, design and development of APIs to consumption and eventually end-of-life. Leverage built-in best practice templates. Publish consistent and meaningful information to your developer portal. Help support both external and internal lifecycles of the API.
Monitor and Manage your APIs with Oracle SOA Management Pack Easily correlate and track events and activities at the developer and API level to understand adoption and measure business value.
Oracle API Gateway
Oracle API Gateway is a standards-based, policy-driven, standalone software security solution that provides first line of defense in Service-Oriented Architecture (SOA) environments. It enables organizations to securely and rapidly adopt Cloud, Mobile and SOA Services by bridging the gaps and managing the interactions between all relevant systems.
Companies worldwide are actively deploying SOA infrastructures using web services, both in intranet and extranet environments. While web services offer many advantages over traditional alternatives (e.g., distributed objects or custom solutions), deploying networks of interconnected web services still presents key challenges, especially in terms of security.
Web services can be implemented using different approaches which need to be secured at the different stages of the request / response cycle between clients (relying parties such as users or applications) and service providers (companies exposing web services).
Several security layers are defined between clients and web services providers. The first security layer, also known as “perimeter security” or “first line of defense,” is referred to as the demilitarized zone or DMZ. The second security layer, or “green zone” to continue with the military analogy, is located behind the inner firewall of the DMZ. In some cases, the green zone may include several security sub-layers designed to further filter access to web services. Finally, agents co-located with the web services or applications to be protected provide the last security layer, or “last-mile security.”