Open API Economy - Right Time For Banks To Flourish

Posted by Kimi Mahajan on Oct 25, 2019 2:39:38 PM

Banking and financial institutions are experiencing some drastic changes with the introduction of API in the Fintech ecosystem. So much so, that the APIs are termed as key enablers to create new value chains and empowering owners of financial data.

While this has accentuated the opportunities for delivering more customer-centric services, regulations and directives are disrupting the understanding and decisions. Let’s understand if it is the right time for retail and corporate banks to opt for API centric ecosystem?

Rising Trends in the Banking Industry

The open API economy is accelerating competition and innovation within the banking industry by creating new demands for banks’ business strategies. It is creating a wave for leading future banks to focus on their end customers and deliver new products and services through collaboration with business units within or outside a bank, across the industry to accelerate their market position.

Europe has taken the lead in API banking space with the Payment Services Directive(PSD2), directed to regulate payment services in the European Union and European Economic Area. It aims to increase pan-European competition and non-banks participation in the payments industry for increased consumer protection for online payments with strong customer authentication. PSD2 has been implemented to prohibit the use of non-transparent pricing methods for international payments to make the customer aware of the real costs involved.

The new regulation will, therefore, help to make international payments as straightforward and secure and will be more competitive offering greater choice for consumers. Its purpose of building a clear and comprehensive set of rules to existing and new providers of payment services will ensure greater efficiency, choice and transparency in a harmonised payment market.

open-api-economy

This digital market trend of open APIs will reduce costs of operation through higher competition, and bring about a new host of products and services through innovation leading to improved customer experience, increased transparency, modernize legacy technology, meet regulatory requirements, and generate new revenue. Banks will witness fragmentation with new competitors entering the market and potentially disintermediation from their customers.

Market disruption, client evolution and regulatory changes in open banking revolution are clear signs in banking and corporate world that customers are being presented with the high-end competition, innovation, and payment mechanisms. 

The Modern Era of Open APIs and Microservices

With the emergence of open API economy, there is a gigantic increase in the number of new entrants entering the financial services markets. Banks are opting for API-first strategies to define their business model, by facilitating their customers to have on-demand products and services. 

Financial Technologies (or simply referred as FinTechs) have disintermediated banks where end-consumers are confident in engaging with a variety of financial transactions, lending or depositing. Bigger technology giants too are advancing their game in the financial services business and exploring the possibilities by entering the payments market and preparing for further disruption.

open-api-economy

Open API banking has lead to an interesting era of banking transformation. Now, banks are adopting short- to long-term strategies to accelerate value delivery through FinTech partnerships. 

However, for its foreseen successful adoption, banks would need to establish the right operating model to drive profitability, ensuring that security standards are conformed with changing business model. As non-banks start accounting for most chunk of customer interaction, banks may find it difficult to differentiate themselves from them and convince customers to buy their services. Hence they would need to refine their data strategy to ensure its maximum leverage.

The banks are adopting microservices-based architecture for application development. It is an approach to which a large application is built as a group of modular services (with a specific business goal) which communicate with each other through open APIs using a well-defined interface. They have the ability to assemble as required to deliver complex functionality, and can scale independently.

The benefit of building microservice-based digital banking solutions is that the entire system won’t be down if one service fails. 

Microservices has brought down monolithic-based applications, focussing more on building agile and scalable solutions. Companies have started shifting towards agile delivery and devops as they would want to move from struggling with legacy applications holding back digital acceleration and innovation. 

This is the time when open API banking combined with microservices-based architecture will define success for banks.

Microservices based web applications are more agile, resilient and scalable. In the current scenario, when banks are seeking to accelerate the digital value propositions at lightning speed for flawless customer experience, opting for microservices approach is the fastest way to accelerate this transformation.

However, banks would need to strategize and will have to rethink their operational support, delivery methodology, and required skills to upgrade its people, process, and technology to enhance their core offerings.

The rising open API economy represents a great opportunity to gain a competitive edge in an increasingly complex and customer-centric marketplace. Despite the strategic and operational challenges, leading corporate and retail banks should realize that the time to act is now.

Topics: Financial Services, API Management

Rolling out API Monetization for a Philippines Telecom Giant with Drupal-APIGEE

Posted by Karthik D K on Sep 2, 2019 12:49:00 PM

With a successful API monetization strategy, enterprises can expand their business capabilities to new customers through the rapid consumption of business assets.

However, with APIs offering dozens of ways to monetizing data, content and technology, it can become overwhelming for enterprises to deal with the entire process.

In this blog post, we’ll take you through the technical knowledge needed to build a robust API monetization platform for Globe Telecom, which seamlessly drove new opportunities and broadened their marketplace.

Understanding Globe’s Concerns and Expectations

Globe Telecom, part of the Singtel Group, is a telecommunication giant in the Philippines with an estimated market capitalization of 3.8 billion USD and a subscriber base of almost 67 million.

It has a programme running on Apigee aimed at expanding the ecosystem and effective productization for increasingly complex APIs. Globe was seeking out to create a prototype for API monetization.

We helped them achieved the following key goals:

  • A unified and well-architected API programme to allow Globe to expand into other avenues faster than before
  • An organized API product strategy with an at least 6-18 months outlook, that allows for better-planned release cycles and innovative business models
  • Standardized infrastructure and ops for resilient architecture, platform security, and cost savings
  • Empowered API teams that can work in an efficient and optimized manner and help migrate selected APIs to the Apigee platform.

Read how Srijan helped Globe Telecom drive its API Monetization Strategy

Take Me Through
Building a Developer Portal on Apigee

A platform was built which could help the client to ideate, develop, and take feedback within planned timelines, with the ability to create new revenue models with an offering for both service providers and end-customers while vastly cutting down development time and costs.

Srijan teams built a unified developer portal which made APIs available to developers to communicate with the actual data in microservices through an Apigee API platform.

The Apigee platform ensured secured use of APIs and acted as the intermediate between developers and the microservices.

The Apigee platform ensured secured use of APIs and acted as the intermediate between developers and the microservices.

Architectural diagram showing communication between developers/admin and microservices

 

Now, let’s understand the features of the project and the various related terminologies.

  • GlobeLabs APIs

The developer portal renders several APIs which can be public, private and internal. These are then implemented on Apigee. The screenshot attached below shows a comprehensive list of Public APIs available to an anonymous end user.

GlobeLabs APIs

Developer portal exposing various APIs for developer use

 

  • Globe Labs ReDoc

ReDoc offers a customizable and incredibly nice theme. It is actively maintained by its developer team to offer a better user experience. It has a custom script written for better readability of a developer.

Here’s the sample doc rendered for:

1. Request

Request

2. Response

Response

  • GlobeLabs SmartDocs for an API

SmartDocs comes as a part of the Drupal-based Apigee dev portal. It provides smart documentation for an endpoint along with a tryout feature so the developer can tryout the endpoint on the page itself.

GlobeLabs SmartDocs for an API

  • Developer Dashboard

A logged-in developer on the developer portal dashboard can choose to create a new app, go to the apps transactions page or see the wallet balance.

Developer Dashboard

1. Developer App

7-3

Screenshot of creating new app interface

A developer can create an app by giving it a unique name, with a particular API product(s) and a callback URL. He/she can select different API types (which are basically API products on APIGEE which gets synced to dev portal) by simply selecting the check boxes.

In case of Consent App, a 'Consent' is a prompt when a subscriber sees while opening an app. The app accesses the list of permissions marked selected by the subscriber.

2. Developer Wallet


Developer can add balance to their wallet via online/offline transfers. The wallet is categorised into two types: prepaid and postpaid.

A developer can have any wallet (prepaid or postpaid) and can even be switched from one to another upon request. The developer will have SMS MO balance attached (see the image below), show the credit/balance history of the transactions done.

3. Navigate Transaction page


The transaction page displays the transaction types and the related balance details.

8-3

Screenshot of Transaction page interface

Admin Operations

Admin does the configurations to communicate between different layers in the entire system. Micro services implement the automated processes across the system wherever needed.

Micro services consists of all the APIs which does any internal operation in the system, and the response is brought back to APIGEE and then to portal/developer App.

 

Srijan is working with leading enterprises across the US, Europe and APAC regions, assisting them with their API lifecycle management with Apigee - creating and exposing APIs and building custom developer portals. Contact us to get started with your requirements.

Topics: Drupal, Planet Drupal, API Management

Powering the telecom transformation with APIs

Posted by Sanjay Rohila on Aug 16, 2019 4:03:00 PM

Moving into round two brought with it the metaphor of The concept of Telco 2.0 has been around for quite some time now. It has been around moving away from the competition with OTT and concentrate on forming complementary ecosystems that benefit both. Telcos began moving away from being mere carriers and becoming more visible within the value chain, essentially transforming from unidirectional to bi-directional business model. 

This meant becoming an ‘enabler’ in the communication supply chain. From proving singular services, telcos started to facilitate an ICT and application platform that could connect diverse businesses and service providers (upstream consumers)  to consumers (downstream consumers) . This model again saw telcos becoming the key link for a wider variety of consumers. 

Telcos are uniquely qualified to become a central broker in this exchange economy because of the amount of data and network infrastructure already at their disposal:

  • Information and Identity: The telephone numbers is a key piece of information that telcos own, and that’s linked to a host of other personal information on users. This also becomes a key identity maker and used for two-factor authentication by most OTTS to strengthen their security. 
  • Business Intelligence: Telcos have a lot of data from both mass and business users, and the tools to leverage that information to better connect service providers to consumers.  
  • Distribution: CSPs own the networks that OTTs use; the fiber, copper, coaxial and wireless broadband networks.
  • Billing and Payments: Telcos have a well established payment relationship with the subscribers, and can become a secure payment broker, offering businesses the ability to seamlessly offer services to a large user base. And for customers, it means ease of payment, either through their mobile numbers or just by adding all payments to their monthly phone bill. 
  • Customer Care: CSPs already have a well established customer care network, with access to a large user base, and the experience to handle care. This makes them uniquely positioned to offer outsourced customer care services to businesses and service providers. 

 

Now, there are several different technology and organizational aspects that need to be addressed to make the telco transformation complete. But a key peg in the whole scheme of things are APIs, especially when you consider how the whole model depends on the ability to connect and deliver information from massively disrate systems. APIs are the very instrument of transformation across technology, network, operations and business services.

We have taken a broad look at how telecom enterprises can leverage APIs to create new revenue streams. Here we try to break that down into the specific teleco APIs that can be turned to new products in the communications ecosystem.

Productizing Different Types of Telecom APIs

To begin with APIs were seen as a solution to expose different types of data and services and allow disparate systems to effectively communicate. However, there has been a recent paradigm shift in how APIs are perceived. They have moved beyond being a mere solution, and are increasingly seen as products that can be leveraged to open uniquely new revenue streams. This productization fuels design thinking and focus on who exactly are the consumers of any given API. And when these consumers are classified, telcos get three distinct types of APIs, with differing levels of complexity and RoI.

Telecom APIs - complexity of productization

Internal APIs

The first level telco APIs are internal, leveraged by their own applications that connect the telco and its various existing services to the consumer. These typically are low complexity API productization models that revolves around the core services. The data and information that arise from the existing infrastructure and network are bundled into API products developed solely by the telco, and made available for usage. 

Some of the common API products in this category are location, messaging and identity services. And these can be leveraged by telcos own-brand applications and OTT services like: 

General information: Applications that share general information about the telso with the consumers - plan options, mobile phone options, accessories available, store locator, ratings, and reviews. All this contributes to the bottomline by ensuring that the telcos offerings are accessible and available to the consumers within the digital economy that they are tuned in to.

Custom information and transactions: Applications that personalize the relationship between the telco and each of its consumers. The first strata of information and functionality being made available here are custom plans and packages for the users, usage data, upgrade eligibility, checking account balance, bill payments, changing account features, account maintenance (password, address, etc.). All of this can be easily made available by pulling information from different internal telco systems via APIs. 

Leveraging the phone hardware: Using telco applications on a phone also makes it easy to leverage mobile hardware features and functionalities - GPS tracking, camera, digital wallet etc. These facilities, in conjunction with the telco’s internal APIs can be used to provide specialized services to their users. A few examples could be providing telco store locations on the app in combination with the phone’s GPS. 

Besides this, internal APIs also streamline intra-organizational access to different data systems, make it easier and faster to build new solutions and applications. There’s ans estimated 5-10% savings  in terms of development effort and lower QA testing requirements, with the adoption of internal APIs. Designing and Implementing an API Monetization Roadmap for Globe Telecom - Case Study

Partner APIs 

These set of APIs are all about creating a platform where other businesses and service providers can build upon. The key idea is to make telecom APIs access data from the telcos own and connected partner systems and make it available for other providers to leverage. Some common possibilities here are:  

  • Content services – streaming media, news, stock information  
  • Online services – social media, video chat, messaging, search, shopping  
  • Technology services – hosting (i.e. cloud), caching, payments  
  • Connectivity services – support for intermittent connectivity  
  • Device integration – smart phone, wired telephone, tablet, computer, television  
  • Business services – analytics, billing, accounting, coupons 

Other businesses can build on these services with their value additions and rely on the telecom to manage the infrastructure and selected business services. 

Specific industry partners can also use telecom APIs to build B2B offerings. They can rely on telcos to offer billing or messaging service APIs to act as key aspects of their service offerings. For example - OTAs can partner with telcos to provide log in/authentication to their portals, payments, notifications, and push custom phone plans for bookings to specific destinations. 

With the rise of connected cities and virtually anything as a service, the phone number can become a singular digital identity for consumers. And almost any service provider, in any industry, can partner with telcos with offer their services, whether that’s by leveraging the data telcos have, or the network infrastructure, or even the phone hardware. All this is if telcos focus on identifying the emerging opportunities and building the right API ecosystem. 

In all these cases, the API products being designed are typically medium complexity and offered with a degree of federated services. The monetization opportunities here are majorly volumetric, as in the third-party service providers are charged as per the volume of API calls made in any given period. 

Partner APIs also make it easier to onboard new partners onto the telcos ecosystem and ensure quick time-to-market for new partner services. An estimated 5-20% savings accrue  from partner APIs owing to the consistent and self-service processes, reduced onboarding time and improved partner experience

Public APIs

Several of the APIs used for internal and partner platforms can be opened to the public for greater use by third-party developers. This allows telcos to further monetize their data and network, while leveraging new revenue streams. 

For example, open access to telco offers and plans data can be used by comparison applications and help drive more subscribers to the telco. Opening up APIs that securely expose user phone number and messaging can allow telcos to charge all third-party applications that use two-factor authentication via OTPs.

Several similar revenue options can open up for telcos with public APIs. However, in most cases, a single telco by itself may not have enough scale or access to data to become a truly game-changing resource for service providers. These are also high-complexity API products that could benefit from co-development models with a greater resource pool. And in such cases it makes sense for CSPs to come together on a federated API platform.

This is when several different telcos join together to offer a host of different APIs and share the cost of development and deployment. The federated platform, on the other hand, supports each participating telco with delivering their niche digital services, managing the full partner ecosystem, and providing common business processes as required. The federated platform also brings together the combined data of all telcos to offer more well-rounded and complete data sets for use by service providers, and manages revenue sharing for the participants.

Most telcos today are at the initial levels of API maturity with a broad vision and some basic APIs at play. Some have an API platform, exposing internal APIs like messaging or payment for third party providers. But the challenge is to scale their API program, unify different development tracks, and move them to a federated API platform. For this, telcos need to look for experienced teams that can take them from what they are, to where they want to be.

Srijan is working with leading telecom enterprises in the US, Europe and APAC regions. We are aiding these enterprises’ digital transformation journeys, leveraging data science and analytics, APIs, AI, machine learning, and chatbots to create tailor-made business solutions.

Rolling out your telecom API initiative? Talk to our experts and let's explore how Srijan can help with API productization, monetization and governance. 

Topics: Telecom, API Management, Digital Experience

Championing the Art of Managing API as a Product

Posted by Kimi Mahajan on Jul 16, 2019 3:01:00 PM

There’s a never before uptrend in API economy. When we think upon the business side of managing an API, it becomes clear that we need to treat the API as a product, in order for it to succeed.

Just like any other product, API as products too have a market with a segment of customers and enterprises leave no stone unturned to maximize its return on investment.

Let’s understand the entire concept of treating APIs as a product and how to manage them as one.

Understanding the Concept

Like any other product, the concept of API as a product aims to help users solve their concerns and get their job done, by outlining its target audience, marketing strategy, development plans, support processes and sales strategy.

Though APIs are believed to be a technical aspect making the lives of developers easy, they are rightfully facilitating business offerings and values.

By viewing the API as their own product, enterprises can focus on creating sales strategies that are relevant and appeal to more potential users.

Watch the video here to know why your API deserves to be treated as a product:

 

 

Usually enterprises leverage their APIs to consumers without thinking about their broader strategic value. Once an organization creates an API, they need to focus on its maintenance, promotion, easy consumer on-boarding, enact right security, instill testing and performance monitoring, developer documentation and consumer support.

How to Manage Your API as a Product

Applying a product strategy to your API will enable it to flourish and generate revenue. The best way to treat the potential APIs as products is to vigorously maintain them, strive for continued improvements by setting up the business side of managing an API. This includes:

  • Building a team of professionals who can advocate the usage of APIs as a product to a large audience, not just limited to developers and gain clarity on what all is expected from the API. A Product Manager will be the best person to interact with the consumer to collect requirements to help identify the best workflow, keeping in mind the final business results.

  • Encourage cross-organizational support to make internal team use APIs collaboratively after APIs become the preferred internal technology for connecting various services and functionality.

  • Identifying developer personas and mapping their customer journeys by documenting and categorizing the problems for different types of developers.

  • Defining a business model and aligning it with the overall business mission to open up organizational culture to new business model opportunities.

There are three basic principles to manage your API as your products which can enable your business to meaningfully expand its ecosystem, accelerate development, and improve efficiency. Here’s how you can champion the art of managing API as a product for a prosperous outcome:

Be Customer Centric

The approach focuses on developer’s problems, and on providing products that help solve those problems.

“Customers don’t care about your solution; they care about their problems”.APIs need to focus on the customer and keep their needs in mind for an API to thrive as a product.


Assume APIs to become Public

The best practice to build an API is to build it in a way to be able to transform it into a public API product in future. Public or Open APIs are created in order to give a wider population of developers access to an organization’s information assets.

Many of today’s successful APIs which were built as private APIs became so valuable that their owners decided to open them up to external developers and monetize it.

Focus on Strategic Outcome

To have a successful strategic outcome for an API as a product, you must arm your APIs with a tactical plan and make all decisions to align your business successfully with your API strategy.

You must have a clear vision of how you want your APIs to succeed and should be equipped with a strong plan for them to grow and become profitable.

To extract maximum ROI out of the API, we need to stay focused on setting up the business side of managing an API. It’s important to sell the benefits of APIs to the right customer and tailor the pitch accordingly.

Conclusion

Businesses have embraced APIs as a way to expose business capabilities to both external and internal developers. They have seen it as a way to reduce cost and ensure faster time-to-market for new services and products, quickly launch own digital services and provide integration with any partners.

Srijan's API Management teams offer API products tailored as per your business needs and can help you with customized developer portals. Drop us a mail and let our experts do the talking.

 

Topics: Agile, API Management

Embracing API-First Approach To Empower Developers

Posted by Kimi Mahajan on Jul 3, 2019 3:33:00 PM

APIs have been around for nearly two decades, but it is only in the past few years, the ‘API-first’ approach has taken up over by storm. The number of developers taking the approach to building products is rising.

So, what makes API-first such a powerful design methodology? Let’s take you on a tour to understand how API-first approach makes the lives of developers easier and why it is their first preference.

Understanding API-First Development

Usually, enterprises keep their prime focus on building web and mobile applications and push the task of building APIs for third-party integration to a lesser priority resulting in inefficiently designed APIs. These APIs sometimes fail to fulfil business purposes.

Through API-first development strategy, enterprises can focus on building API as the first line of business, not restricted by constraints of the existing business requirements.

The approach focuses on building products (in the form of a website, mobile application or SaaS) in favour of developer’s interests.

The API-first approach recognizes the APIs as a first-class artifact of the entire development process. 

Let’s understand how it differs from the traditional approach.

Traditionally, once a new service or a new feature is in a need for development, the R&D teams brainstorm to work on the design, followed by backend team to create a prototype API. The API is then circulated along with an API document to front-end teams and testers to test it. Finally, the front-end teams and testers build SDKs, tests, and more to interact with the API. This entire process is referred to as synchronous development.

This approach wastes valuable development time of the developers, as most of the time they are waiting for testers to test APIs and changes to be released.

This overall increases the time-to-market for the entire product.

understanding-api-first-development

Source: dzone.com

 

Whereas, API-first development allows development teams to work in parallel without the need to wait for changes to be released by one team, with the help of ‘mock APIs’.

Mock APIs help the developers to get started with web service development without waiting for API teams to create APIs. And if they haven’t decided how to design the web services, mocking allows them to rapidly prototype different potential responses to see how they work with the app. And soon they can switch to the real web services when the APIs are ready.

The back-end, front-end, and test teams start to work with the mock APIs and once the API is ready, all teams then switch to the production or staging API, saving a lot of development time.

mock API First Approach

 

Source: dzone.com

API-First Approach Benefits Developers

An API-first approach has various benefits to building products, including but not limited to:

Empowers development teams

API-first approach involves developers to work on mock APIs instead of working on creating APIs as a first step. The developer teams across an organization work on multiple web services at the same time and do not have to wait for updates to be released before moving on to the next API.

The testing becomes easier as testers have to test API dependencies based on the established API definition. Testing of APIs comes later in the process only when they are ready.

Several automation tools available makes life simpler for developers which generate API documentation, style validation, API mocking, and versioning.

APIs self-service portal also helps developers to get started building apps with their APIs right away.

Ensure rich developer experience

As API consumers are developers, API-first ensures that developers have positive experiences using the APIs. Developer experience can majorly impact the success of an API.

Well-designed, well-documented, consistent APIs provide positive developer experiences. So, when it is easier to reuse code and onboard developers, it improves the learning curve, hence increasing the developer productivity.

When developers have easy access to APIs, testing tools, blog posts, forums, and other features, they can quickly create API programs and get to know potential opportunities about their customers.

Increases success ratio

It reduces the risk of API failure and ensures the APIs are reliable, consistent, easy for use as they can impact every part of your business positively or negatively.

Reduces development effort

APIs and code can be reused on several different projects which implies that the development team don’t have to start from scratch and can easily make use of APIs built as per their needs.

This approach reduces the effort of reinventing the wheel, which can be time consuming and costly.

Impacts speed to market

Much of the process of building APIs can be automated using tools that allow the import of API definition files (and with those files API tools such as API documentation, SDKs, and mock APIs can be auto-generated) which speeds up the development of APIs and applications.

Also, the approach makes it possible to add new services and technologies to applications without having to dig deeper to re-architecturing the entire system.

The competition of developing applications is extreme expecting the apps to be developed and marketed quickly. Today, applications must not only be well designed but designed to market at the earliest.

Conclusion

Empowering developers through the API-first approach to building products can benefit your organization in innumerable ways.

Srijan is working with leading enterprises- enabling innovators across different industries, and assisting with their API Management Lifecycle to leverage API-first approach.

Ready to execute a profitable API strategy? Drop us a line and let our expert API team advise you with your next steps.

 

Topics: API Management

Next Steps to Securing your Apigee Drupal 7 Developer Portal

Posted by Kimi Mahajan on Jul 2, 2019 4:02:00 PM

As of May 31, 2020, Apigee will no longer sponsor hosting of Drupal 7-based developer portals (D7P). Prior to this, starting on May 31, 2019, Apigee will no longer provision Drupal sites for customers. 

Developer portals are expected to give flexibility and control to the developers and keep users’ data secure on a daily basis.

In our previous blog - Should You Migrate Your Developer Portal To Drupal 8? - we detailed on the security challenges your Drupal 7 developer portal could face, after all, security is important.

In this blog, let us understand the best action plan you can take to secure your developer portal. 

Action Plan to Secure Your Developer Portal

As a service provider, you have developed a set of APIs to provide access to your backend services. The announcement can put you in a fix but whatever your choice of action steps, ensure the end result can: 

  1. Keep your data secure
  2. Should not hamper the current flow of work
  3. Should be able to integrate with Apigee

Currently, you have three options in place:

  • Remain on Drupal 7 and assume hosting responsibility
  • Move to Apigee's integrated portal
  • Migrate your developer portal to Drupal 8

Remain on Drupal 7 and assume hosting responsibility

If you need (more) time to decide whether to opt for migration or not, depending on the existing running projects - you can consider remaining on D7P until you finalize on your choice. 

The support of the modules which integrate Drupal 7 with Apigee Edge will not be affected, however, cloud customers would need to assume direct account responsibility with their hosting providers.

After May 31, 2020, all Apigee-hosted Drupal 7 developer portal will be decommissioned and will be unavailable. You would not be able to administer or develop any post-May 2020. 

Remaining on Drupal 7 could make you vulnerable to several security concerns as discussed in our previous blog.

Move to Apigee's integrated portal

Consider moving to an Apigee integrated portal, if you have been using Drupal 7 with a minimal amount of customization or prefer an all-in-one solution. 

It is integrated directly into Apigee Edge and includes a powerful API catalogue and a compelling markdown-based CMS with robust audience management tools.

However, if you are someone who has leveraged the functionality of Drupal 7 in conjunction with a high degree of customization and investment in crafting a specific developer experience, then you should consider switching to Drupal 8. 

Migrate your developer portal to Drupal 8

Drupal 8 remains to be a compelling option for those who wish to remain on Drupal for their developer portal. It is the option preferred by the customers to head towards a self-managed developer portal and as a path forward to leverage the latest functionalities of Drupal.

There is a host of functionalities in Drupal 8 which makes it a better option from the three. It is more secure than Drupal 7, more features than on Drupal 7 and proves to be an ideal option for the developer portal to be built on. Let’s learn about them.

Your Drupal 8 Developer Portal will be Secure

Here is a list of new features introduced in Drupal 8 which aims to enhance the security of your developer portal:

  • Twigs: A new theming layer which comes with a whole bunch of security features.
  • Configuration management: You have a list of all configurations of your site in your code so as to let you know what all settings have been changed and who is responsible for that, when and why and to know what all settings have been changed.
  • No PHP filter: Simplifies the process by allowing developers to code inside a node.
  • Session IDs hashed: Now session IDs in the code are hashed, so even when the session IDs are known, the sessions cannot be hijacked.
  • Trusted Host Patterns: Code knows when it is in a trusted environment and alerts  when it is not. 
  • Single Statement Limitations to DB queries: Doesn’t allow multiple statement query in a single database.
  • Mixed Mode SSL removed: Implying the SSL will be used anyway and is no way an option now.
  • Automated CSRF token protection: Able to detect if the forms have cross-site scripting going on.

Some Best Practices To Mitigate API Threats

To secure your digital property from any possible threats, you need to follow certain best practices to ensure safe usage of APIs and prevent any critical customer information leakage.

  • Encrypt the APIs: Decrypting the API keys by authorised users will protect the critical data from being misused.
  • Ensure Role-Based User Authorization: Authorizing registered users as per roles to access APIs can work to identify a user and classify them as per varying levels of permissions.
  • Allow only Registered users: The first and foremost step is to authenticate users using the API in order to protect information. It becomes easy to track the API usage and identify who is making what request.
  • Deploy Rate Limiting: It can detect and prevent an unusual number of requests from a given user at a given frame of time. In an exceptional case, wherein the attacker manages to bypass your encrypted authentication and authorization protocols, rate limiting can prevent your API from being compromised.
  • Build Security in Layers: If the above steps don't work, try adding an extra level of security through an outer firewall.
  • Security is required in back-end too: Another checkpoint on the way out of the network can thwart the attacks is to secure the system down up so you can track him down on the way out. 

Srijan Can Help

Srijan is committed to providing customized developer portal to help you attract and engage developers with a comprehensive, customizable developer portal that offers a seamless onboarding experience. We offer secure migration of your existing developer portals to Drupal 8. 

Want to upgrade your developer portal? Let’s start the conversation

Topics: Drupal, Planet Drupal, API Management

Should You Migrate Your Developer Portal To Drupal 8?

Posted by Kimi Mahajan on Jun 23, 2019 5:22:00 PM

Apigee recently announced that it will end its sponsored hosting for Drupal 7-based portals from May 31, 2020. The existing customers who wish to remain on Drupal 7 based developer portals need to assume hosting responsibility. Alternatively, they can either migrate to Drupal 8 or move to Apigee's integrated portal.

Those who wish to stick to Drupal 7 developer portals might possibly face challenges. While Drupal remains as one of the most secure content management system (CMS), there is still a need to actively consider migrating your dev portal to Drupal 8.

Here's why.

Drupal 7 End-of-Life is Near

The developer portal is essentially a CMS, in case of APIGEE, based on Drupal. As the backend CMS, Drupal provides a core set of features in the form of modules that make it easy for you to build the content, as well as manage websites.

Developer portals orchestrate the API ecosystem which helps developers and external partners to quickly and securely gain access to the tools and information they need to explore, test, & consume APIs.

APIGEE supports several developer portal solutions, ranging from simple turn-key to fully customizable and extensible, with most of them built on Drupal 7. However, with community focus shifting to Drupal 9 release and end-of-life approaching for Drupal 7 (November 2021), among other circumstances, APIGEE will no longer be supporting the D7 developer portals.

With APIGEE support ending in May 2020, Drupal 7 developer portals will face some serious security challenges.

Drupal 7 Can Put your Developer Portal at Risk


While Drupal has sophisticated security features, no Drupal implementation works in isolation. If you want to secure your digital property from all possible threats, you needs to follow best practices to ensure that its secure both in itself, and in its interactions with all other systems.

And one of the most important ways to do that is keeping the core updated.

If you fall way behind the latest update, you are opening yourself up to vulnerabilities. Here's a closer look at how Drupal 7 can put your developer portal at risk.

1. Doesn’t prevent cross-site scripting

Cross-site scripting (XSS) is a class of code vulnerabilities that allows code to be executed inside your browser without your consent or knowledge. XSS exploits are commonly performed with JavaScript, but Flash, Java, and other similar web programming technologies have been used.

It is one of the most frequent security vulnerabilities that a site owner should be aware of. It can be introduced in custom themes and custom-and-contributed modules. A poorly configured site can allow a malicious visitor to use XSS to change a user's password.

Out of the box, Drupal 7 isn’t very effective to identify and fix XSS vulnerabilities.

In Drupal 7, elements like Drupal variables or Ctools exportables are represented as PHP code. This use of PHP input format in the core exposes possible code execution to vulnerability.

Drupal 8, however, filters the PHP input format in the core, manages code in a revision control system like Git, and protects the code from any possible attack. Configuration Management Initiative uses YAML as the export and import format. YAML files are easy to manage together with your code and it is a best practice to check it into a revision control system.

2. Exposing session cookies

Drupal 7 stores the session ID and checks directly against the incoming session cookie from the browser. This poses a huge risk as the value from the database could populate the cookie in the browser assuming the session as well as the identity of any user who has had a valid session in the database.

On the other hand, Drupal 8 secures the session IDs against exposures via database backups or SQL injection, encourages serving your entire site via secure channel SSL and no longer strips the www from the session cookie domain.

3. No Automated CSRF token protection in route definitions

Cross-site request forgery (CSRF or XSRF) is a process where a request is made to a site which takes an action when the user did not intend to take that action.

GET requests with configuration change are not protected from CSRF in Drupal 7. This brings all the secure and unsecured requests under the scanner.  However, Drupal 8 makes it easy to specify a route (or system path) require a CSRF token.

4. No Clickjacking Protection

Drupal 7 cannot protect a site from click-jacking attacks wherein forms or links on the site are presented in a disguised fashion on an attacker's site inside an iframe. It cannot block the unauthorized re-use of site content via iframes too.

However, Drupal 8 does this easily by sending the X-Frame-Options: SAMEORIGIN header in all responses by default. This header is respected by most browsers and prevents the site from being served inside an iframe on another domain.

Should you Migrate your Developer Portal to Drupal 8?

When choosing a solution, you need to balance your customization requirements against the time and knowledge required to implement your portal. Migrating your developer portal to Drupal 8 will ensure that any investments you make will extend the security of your digital presence.

Have doubts around your API security or want to migrate to Drupal 8 developer portal? Get in touch with our experts. We provide a range of services around API designed with a strategy tailored to your success.

Topics: Drupal, Planet Drupal, API Management

API Automation using Postman

Posted by Deepshikha Singh on Mar 26, 2019 6:01:00 PM

If you are new to Postman, please visit my blog API Testing using Postman for an overview of what Postman is and how it  works.

Automation has now become a norm across sectors, and when used in testing, it can undoubtedly improve the depth and scope of the tests. Since it is not possible to test everything manually, so using Postman automation can save our time as well as efforts.

Postman is the ultimate tool for API automation. In this blog, we will be taking a look at how to achieve API automation using Postman.

Example Scenario for Automation using Postman:

Let’s say, a login API generates a Token (oAuth, JWT etc) and refreshes it every hour. The API utilizes this token to get the expected response. If we don’t automate, we will have to copy and paste this every time for each API.

And for a test suite containing 100 API’s, a good amount of manual effort will go into pasting the token for each API. By introducing automation, this process of updating the newly generated taken can be automated.

Let’s automate the Login API through Postman

  1. Open Postman Application and create a collection.

  2. Then make a POST request to Login API by passing the correct credentials (Body Parameter+Header)

    api-automation-using-postman-srijan-technologis

api-automation-using-postman-technologies-1

3. Now click on Send button to see the response.

api-automation-using-postman-srijan-technologies-2

4. In the above response, we get an “access_token” key which would be used in all the following API’s. Hence, we need to write a custom code which can define the variable, and update its value with every hit to the Login API. Going further, we will use this variable for access_token value and would not need to copy and paste the access_token value for each API.

5. Also, we can create the variable for host_name, protocol etc so that we don’t need to write the protocol and host_name for each API, instead we can use the variable.

6. Another important aspect is to check for correct Response/Status Code and the Response Time for each API. It would be really great if we can write the code for this task too, so that when we run our entire API test suite. We can easily view all the failing tests which does not give correct status code as well as all those API’s which are taking more than an acceptable response time to execute.

7. Below is the sample code snippet which would solve all the above problems.

Srijan-technologies-api-automation-using-postman

8. You can see the value of access_token is set in the environment variable as expected.

api-automation-using-postman-srijan-technologies-3

9. Also, under TestResults tab you can check if the assertions you wrote have been passed or failed.

api-postman-using-postman-srijan-technologies-4

10. Postman itself provides us with lots of code snippets, you just need to click on the desired code snippet and the generated code adds in the Tests tab to perform assertions/actions. To get the snippets, click on Tests tab and then on the arrow “<” to see the snippets.

test-sricpts-written-in-java-scripts-srijan-technologies

11. If you want to add more custom code, you can always do so depending on your requirements, a couple of them are mentioned in the screenshots below:

api-automation-using-postman-srijan-technologies-5

api-automation-using-postman-srijan-technologies-6

srijan-technologies-api-automation-srijan-technologies7

srijan-technologies-api-automation

That’s all for this blog. Happy Testing!!

Topics: API Management, Coding and Tutorial

Manual API Testing using Postman for Beginners

Posted by Deepshikha Singh on Feb 27, 2019 6:19:00 PM

Manual API Testing using Postman for Beginners

Reliable API calls are critical to any decoupled application. Whether it a simple configuration change to an entity or updating the Drupal core, both of them can alter the API response and lead to application-breaking changes on the front-end. An API test suite can watch out for these API breaking changes by running a slew of tests against your endpoint. And when you need to create an API test suite, Postman delivers.

Why Postman tool?

Postman is a simple GUI for sending HTTP requests and viewing responses. It is built upon an extensive set of power tools, which are incredibly easy to use. Postman helps you perform a variety of functions ranging from

  • organizing requests into collection and folders,

  • sharing common values across requests with environment variables,

  • scripting tests with the built-in node.js based runtime,

  • and at last, automating it all using Postman’s very own CLI — Newman.

 

Install native Postman Application

Postman for Mac/Windows/Linux:

Go to https://www.getpostman.com/apps  and download the application based on the OS you are using and follow the steps prompted to successfully install the Postman application.

After you have installed Postman successfully, your postman window should look like:

manual-api-testing-using-psotman-srijan

If you have accomplished this step, you are all set to take the next flight.

Making the first http request in Postman:

Since we have installed the Postman app successfully, it is now time to start testing the API with Postman by making first ever HTTP request to server.

What is HTTP?

The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers. HTTP works as a request-response protocol between a client and server. A web browser may be the client, and an application on a computer that hosts a website may be the server.

Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.

 

Most common http methods:

1. GET : The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.

2. POST : A POST request is used to send data to the server, for example, customer information, file upload, etc. using HTML forms.

3. PUT : PUT is used to send data to a server to create/update a resource. Replaces all the current representations of the target resource with the uploaded content.

4. PATCH : PATCH is used to update partial resources. For instance, when you only need to update one field of the resource, PUTting a complete resource representation might be cumbersome and utilizes more bandwidth.

5. HEAD : HEAD is almost identical to GET, but without the response body. HEAD transfers the status line and the header section only.

6. DELETE : The DELETE method deletes the specified resource.

7. OPTIONS : The OPTIONS method describes the communication options for the target resource.

Testing GET Requests

Let’s now jump directly to test those API’s. Suppose we have an API which fetches the user information of a particular application. To test this we will have to use GET request. The GET request is explained below:

For sample requests, visit https://reqres.in/

a. For making the first HTTP request(GET):

  1. Make a collection in Postman — To make a collection in Postman, click on New->Collection->CollectionDemo(Any Collection Name you wish)->Create

  2. Make a Request — To make a request, click on New->Request->GetUser(Any request name you wish)->Select the Collection you wish to save request in(Present in bottom of dialog box)->Save to Collection Demo

  3. By now, we have created our first request, now we need to pass different parameters in the request to get the expected response.

  4. In the “Enter Request URL” text box type : https://reqres.in/api/users?page=1

  5. Click on “Send” Button

    manual-api-testing-using-psotman-for beginners-srijan-1

6. You should be able to see the below response in the Body section:

manual-api-testing-using-postman-for beginners-srijan-1

7. You should be delighted you have successfully tested your first API request.

Testing POST Requests

Now, suppose we need to create a user into a application that means we are sending data or feeding data to an application. For these type of requests we use POST request. In POST request we send data/parameter in the body of the request, and in response to that, API returns some data to us which validates the user has been created. The response can either be a success message or the id of the new user created and time when the user was created.

a. For making the first HTTP request(POST):

POST Request — To make a POST request, click on New->Request->CreateUser(Any request name you wish)->Select the Collection you wish to save request in(Present in bottom of dialog box)->Save to Collection Demo

  1. From the Dropdown select POST

  2. In the “Enter Request URL” text box, type : https://reqres.in/api/users

  3. Click on Body Tab and select “Raw” radio button

  4. In the text box, paste :

{
   "name": "morpheus",
   "job": "leader"
}

5. Click on Send button

6. User should see the below response:

manual-api-testing-using-postman-for beginners-srijan-2

7. Also, check for correct status code, in this case you should get : ‘Status:201 Created’

manual-api-testing-using-postman-for beginners-srijan-3

You have successfully tested your POST request too, similarly you can try your hands with PUT, PATCH, DELETE etc.

  1. Check for expected response.

  2. Check for correct status code.

  3. Check for Time (Response Time), it should be acceptable as per business.

  4. Always perform negative tests to verify that the API doesn’t respond if data is tampered.

That’s all for this blog. Happy Testing!!

Stay tuned for my next blog on “Automation with Postman”

Topics: API Management

How Telecom Enterprises can leverage APIs to create new revenue streams

Posted by Sanjay Rohila on Dec 28, 2018 12:39:00 PM

The telecom industry is said to be approaching a tipping point. While revenues might not exactly be falling, there is a definite slow down in growth. With little focus on introduction of new services, most communication service providers (CSPs) are competing over the same existing market, and experiencing high customer churn rates.

Current Challenges in Telecom

At the heart of this crawling growth are a few key challenges that telecom enterprises have to address:

Staying Relevant to the Customer

Everything that one could do over the phone can be done over the Internet today. Messaging, voice, and video calls are all being offered by a host of applications. OTT services have become the primary point of connection for consumers when it comes to communication; be it messaging, video calling, and increasingly voice calling as well. And they appropriate a large share of the revenues generated as well.

OTT revenue cannibalization - Telecom API blog

Source: www.mckinsey.com quoting Ovum; McKinsey analysis

In the absence of any new value-added services, telecom operators have become mere connectivity providers. And even if they focus on improving connectivity, say with the introduction of 5G, customers are likely to take it for granted.

The bottom line is customers hardly recognize the relevance of the telecom provider in their communications. One telecom provider is as good as the next one, because everything they care about is actually delivered by OTT services.

Lack of New Business Models

In order to be noticed by the customers, telecom operators have to develop and deliver new services. And that is proving to be an uphill battle because they are hardwired to build networks.

Within the existing structure and leadership, the dominant response is to drive down cost on network operation to remain profitable. And while that is a way to go, it’s not enough. Telecoms have access to a lot of network assets and data that could potentially give rise to new services. But change is always resisted, and hence CSPs have not been able to develop new business models for revenue.

Slow Technology Adoption

Along with a change in the business strategy, telecom enterprises will have to optimize operations to even begin to deliver new services. They will also need new technology expertise to create and deliver value-added services. But once again, this is an aspect that CSPs have been slow to adopt.

How Can APIs help Telecom Operators

Telecom APIs can be a key piece for telecom operators to transform their value propositions.

Developing New Services

API gateways are the most efficient way to access and use information assets stored across legacy systems. Telecom operators already have huge amounts of user data, and APIs are the most secure way to expose this data for developing new services at scale. This would be true for both B2C and B2B services.

Hybrid B2C Services: APIs give telecom operators the opportunity to share information assets with other third-party service providers. This could lead to the development of hybrid services that can compete with existing OTT services.

A key example of this would be customer authentication services. Since telecom operators offer connectivity to all manner of services, that can be the unified access to all of these services. A one-step login to all applications would be a major convenience for consumers, and also bolster data security. And this would strengthen telecom’s collaboration with other service providers.

Value-added B2B Services: B2B enterprises present a highly profitable market for CSPs because:

  • Enterprise are willing to pay more for value-added services
  • Lower chances of being usurped by OTT service providers, at least in the near future

 

Exposing APIs is one of the most convenient ways to productize existing telecom assets, and create custom solutions for B2B enterprises. The opportunities here could be in the form of:

New Solution Bundles: Given that CSPs already own and operate widespread networks, they can offer new solution offerings that provide the usual gateways for voice and video calls, messaging, bundled with payment gateways and location services enabled by APIs.

Data as a Service: A host of enterprise applications rely on communication databases to deliver services. CSPs have access to vast amounts of user data, which can be made available to enterprises via APIs, as they build new customer solutions. Telecom APIs can monetize this data sharing to add new revenue streams. They can also create APIs that allow the CSP’s billing systems to be used by enterprises, charging a transaction fee for the convenience.

Monetizing Network Assets

Telecom operators have a set of core assets that are being utilized by OTT services. APIs offer a way to commoditize these network assets and create new revenue models:

Flexible Charging Models for Network Usage by OTTs

The network established by CSPs is their biggest asset, and the key to OTT services being able to deliver value to customers. APIs can help efficiently monetize this asset and create variable charging models for different types of OTT services. They can be charged on the basis of volume of usage, number of transactions, or other custom models as applicable; and this is managed by telecom APIs.

IoT Ecosystems and Edge Augmentation

With the rise in interconnected device ecosystems, telecom operators have a huge market just waiting to be leveraged. There’s B2C categories like GPS and other telematics devices, and also B2B use-cases where machine-to-machine communications, both wired and wireless, are witnessing large-scale adoption. Since all data is being transmitted over carrier networks, CSPs can create new pricing models for network usage.

Telecom operators can offer computing capabilities closer to the source of data generation, at the edge of the networks. Telecom APIs can be the key to transferring IoT data to computing applications and to the end user.

Srijan is working with leading telecom enterprises across US, Europe and APAC region to drive their digital transformation via successful API management, monetization, and governance. Let's get the conversation started on how Srijan teams can help leverage APIs for your enterprise.

Topics: Telecom, API Management

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us