API series - SnapLogic: An engineer's view of the API universe

These thoughts on API management form part of the Computer Weekly Developer Network’s API series and come from Kamakshi Narayan in her role as director of product management at SnapLogic – the company is known for its iPaaS platform empowers enterprises by automating application, data and cloud integration

With over 600 Snaps to choose from, SnapLogic makes it easy to create simple workflows or complex business processes between cross-functional work groups – and so automate entire ecosystems of applications, databases, APIs, data warehouses, devices and more.

CWDN: How do we ‘scale’ API management in the webscale world of cloud computing and the expansive road ahead?

Narayan: An API Gateway is equipped to scale in response to increasing volume and traffic, whilst API management solutions must offer flexibility through a consistent service between on-premise, cloud and hybrid models and by managing these APIs closer to the applications or users. 

A key component of scalability is achieved through migration to the cloud. This has changed from becoming a business driver to a business necessity, with companies adopting scalable ‘as-a-service’ business models through embracing cloud platforms.

As a business’s API and product footprint expands to more regions, channels, users and applications, a cloud-based solution allows companies to meet these challenges with a reliable, extensible platform that can achieve better business outcomes.

CWDN: When is an API not an API?

An API is a contract that enforces the rules of engagement and communication between two parties: as such an API ultimately never ceases to be an API, if its purpose is to transport data and information and perform operations in a methodical and standardised manner.

The effectiveness of an API can however, be reduced, if the API is not widely publicised and shared. This restricts other applications and end users’ ability to use the API for various purposes. It becomes costly and inefficient for an organisation to build these services repeatedly and not utilise them to their maximum potential.

CWDN: How do we catalogue and manage APIs on a day-to-day basis?

Narayan: The concept of service discovery is an age-old one, starting in the networking world, with the principle that new resources need to identify themselves to be considered part of the network. Similarly, whilst API discovery is still an ongoing challenge, it can now be addressed through multiple ways via API cataloguing and discovery, with tools like API Management and API portals. These are necessary mechanisms that help organisations advertise their products and reach a wider audience.

The API Catalog is a rich tool that allows users to discover and learn about an organisation’s products (aka services) and provide all the necessary information that is important to learn how to use them. API Management provides the ability to share these APIs through the portal in a streamlined and consistent manner.

CWDN:How important are open standards to the life of working operational APIs?

Narayan: Several initiatives (like Open Stack Foundation) have already been consolidating around the idea and notion of Open Standards. Organisations can achieve better scalability, extensibility and reusability of APIs through a standards-based approach for communicating, developing and sharing APIs. 

Kamakshi Narayan, director of product management at SnapLogic.

These standards unite developers and consumers to build a culture and practice around producing and consuming services based on Open API Specifications. Accepted security standards like Open ID Connect and OAuth, just to name a few, help an enterprise organise their medium of connecting and sharing data and information between users and systems, through a secure, reliant and industry-accepted manner.

CWDN: How do we achieve unified monitoring of APIs from a security perspective?

Narayan: The right API Management solution gives organisations peace of mind from a security and threat protection perspective with a monitoring component that’s part of the solution.

Screening and protecting users who access the services can be achieved through an API policy model. Unification of security and compliance standards via API governance is a good way to ensure that organisations stay protected and guarded when it comes to managing their API ecosystem.

Centralised monitoring controls, dashboards, auditing mechanisms and the ability to create alerts and notifications for security violations can arm IT and Operations teams with proactive tools to react to situations before they spiral out of control.

CWDN: The core API management functions include authentication tools, rate-limiting controllers, analytics functions and ______ what would fill in the blank?

Narayan: API Lifecycle Management. An API can be managed well only if it is designed and built with purpose, tested and validated for its use by users.  A best of breed API Management platform will provide a complete set of capabilities to address the entire lifecycle of an API, from creation to deployment and management.

CWDN: Is a governance control plane needed to keep APIs where they are supposed to be doing the job they are supposed to be doing?

Narayan: In API Management, the control plane is a single, controlling layer in the system infrastructure for centralising and managing all API-related activities. The governance (management) plane is between the control plane and the data plane, managing the system wide policy controls and configurations applicable to all services, APIs and applications. 

Separation and segregation of access to components in the system architecture achieves better efficiencies for all connected stakeholders like IT Operations, business units and teams, in managing the API ecosystem.

The biggest threats to a company’s resources and systems are exposed via inefficient security mechanisms or governance controls and the lack of good gatekeepers. The management plane can provide the inner, core and outer perimeter of the organisation’s system architecture with specialised functions and capabilities to protect, scale and operate them much better.

CWDN: Where does API testing come into the API lifecycle and how should it be carried out?

Narayan: With API Testing, validation is introduced in the API Lifecycle in two different stages and performed by two different actors.

The first is API testing by an API provider or developer after the completion of design and development. Testing can be carried out by tools, provided in the API Management solution, to validate the structure performance and built-in security checks enforced in the API.

Second, is API validation carried out by the consumer before using the API, deciding if the API is the right service to use in their application.  This validation can be done by the consumer from the API developer portal through mock testing or experimentation. This enables the consumer to learn about the structure of the API, the inputs to be provided and what to expect as output.

API Testing must be done for each iteration of the API when it gets versioned, modified, or enhanced.

CWDN: The most common architectures for APIs are Representational State Transfer (REST) and Simple Object Access Protocol (SOAP), both of which technologies work to defines a standard communication protocol specification for XML-based message exchange… what should API users, developers and architects consider in this space?

Narayan: REST and SOAP both have their space carved out for them in the API ecosystem. Increasingly, companies are starting to embrace REST as it becomes an accepted API framework for building lightweight applications. SOAP, on the other hand, whilst comparatively slower and harder to develop, supports transport agnostic protocols and provides additional security. This means that SOAP frameworks are for function driven purposes for distributed systems.

Ultimately, there is no right or wrong answer in choosing between REST and SOAP – the choice is driven by the purpose and objectives of the API.

CWDN: How do should firms look to monetis (and perhaps productise) their APIs, what does this process involve and what part does it play in the total API lifecycle?

Narayan: API products are created as part of an API Lifecycle, managed by an API Management Solution. As part of the overall lifecycle, an API Management solution supports many stages specifically focused on the creation and deployment of API products. The APIs are offered to end consumers via an API Developer Portal — this is where businesses find value in acquiring users for their APIs and rolling out a business model based on the consumption of the API.

Different classes of users require different levels of usage for the same API product. Creating specialised packaged offerings of APIs for users based on the consumption via subscription mechanisms would allow an organisation to monetise the product. Customised and targeted presentation of these products to users can be achieved through the API Portal, along with the ability for a user to experiment with the API product before signing up for a subscription.

APIs should be treated as products and a manifestation of the API is represented as code. Approaching and building APIs as products provides pathways to solve complex problems and a create a solution which offers a wider range of uses. APIs then naturally become more consumer-friendly and can be continuously managed, measured and improved for multiple teams and users. An API product mindset and API-led strategy offers the promises of agility, autonomy and acceleration to any business.