A Catalog is a target for deploying APIs where it has a gateway and (if desired) a Developer Portal service. A Catalog is a logical partition; therefore, you can have many Catalogs for a Provider organization. With the proper permissions within the Provider organization, you can create additional Catalogs to represent various environments. It’s not uncommon to see environments such as Test, QA, and even Production created for a Provider organization.
As mentioned earlier, Developer Portal services can be created for a given Catalog. This is not a requirement. So, why would you not want a portal for every Catalog? Well, Catalog Developer Portals are really tenants of the portal service. If your Developer Portal service is limited in capacity, having multiple portal tenants might stretch your resources. In addition, Catalog Developer Portals require configuration, so if you would rather not have to configure a Developer Portal service for each of your Catalogs, then you can decide not to have a Developer Portal. You will learn about Catalogs in greater detail in Chapter 3, Setting Up and Getting Organized. Additionally, in the same chapter, you will learn how to create a portal tenant for a Catalog.
That was a quick introduction to the Cloud Manager and API Manager components along with their capabilities. Next, you’ll learn about the portal service.
The Developer Portal service
In this section, you will learn about the portal service. As mentioned earlier, the Developer Portal service is a multi-tenant portal server that holds the Developer Portal tenants created by the Catalogs. In version 5 of API Connect, the Developer Portal was based on Drupal 7; however, in version v10.0.1.5, it is now based on Drupal 9. The benefit of using Drupal is that it is a content manager that enables you to create incredible digital experiences. What you should know is that this is an enterprise-enhanced version of Drupal that includes plugin components of API Connect. These allow integration between the Developer Portal service and API Manager.
The following screenshot shows the default Developer Portal home page. The components of the Drupal Developer Portal service are also containerized, so this Drupal instance is running under Kubernetes:
Figure 2.7 – The Portal instance home page
As mentioned earlier, Drupal is packed with additional functionality for API Connect. So not only is it an awesome content manager, but it’s also a full-fledged API socialization platform for APIs. From a digital transformation viewpoint, it fits right within the plan.
You’ll learn more about the customization capabilities of the Developer Portal service in Chapter 15, API Analytics and the Developer Portal.
In the meantime, you should attempt to understand the API Connect capabilities that are incorporated in the Developer Portal.
Digital transformation portal API Advertising
The subheading is a fancy way of introducing the capabilities of API Connect, but in a nutshell, you can simply refer to it as the Developer Portal. The Developer Portal can be used to discover APIs and develop new applications. This utilization is not just for external consumers and business partners, but it is also a perfect way to integrate internal applications. In fact, many API Connect enterprises utilize it internally as part of their initial digital transformation effort. Making their internal applications successful provides them with the confidence to extend their API effort beyond the firewall.
So, what are the capabilities of the Developer Portal? First and foremost, it has the ability to showcase your APIs. This is accomplished with the content manager by providing a Product page. The Product is the packaging for your APIs. A consumer will visit the portal and peruse the Product page, review the documentation for the product and its APIs, and, finally, determine whether the product is something they would like to try out.
With the Developer Portal, you can configure it to only allow logged-in users the ability to view these products. That will depend upon your business requirements. Can anyone see them? Or do you want to implement a mechanism that requests the user to log in? If that is the desired behavior, you can set up self-service registrations where a new user registers and creates a consumer organization. A consumer organization is an external organization or developer. One marketing strategy is to capture the consumer organization information as a means of doing more business. There is a built-in workflow that can be initialized to verify self-registering consumers to your Developer Portal. This can be accomplished via an email to a community manager who can then authorize the new registration request. That gatekeeper can accept or reject that person and/or use the information provided to reach out to the person to sell your APIs as the best in the world – this is a powerful capability.
Regardless of which method is used to get the consumer on board, once the consumer has access, they can review the Product and APIs and choose to subscribe to the Product. When subscribing, the user selects a plan to subscribe to. Plans set limits regarding the utilization of your APIs. Similar to a healthcare plan, the user chooses options that give them the capabilities within the multiple plans your Provider organization has agreed to. Once subscribed, the consumer can begin testing the APIs. This is similar to a test drive of your API. Try it out. See how it behaves; see what type of security is required and what return codes are provided – everything you need as a developer to build a robust application.
It is important to note that we have mentioned a few capabilities that are provided by the portal. You have heard about Consumer organizations, consumers, Products, APIs, subscriptions, and plans. All of this information is part of the API Connect additions to the Drupal portal software, and it’s all persisted. Beneath the covers, the portal is communicating with API Manager. It’s the API Manager component that contains the database that holds all of API Connect’s critical assets.