The Fragmentation in API Tooling: Specialized Tools, Inefficient Processes

The API management world is certainly a difficult one to navigate, especially for beginners. I can tell from my own experience that when starting my journey in API management I was kind of blown away with the number of tools that are out there and available. Most of these tools have been created in order to challenge the API tooling status quo and claim to be the “ultimate solution”, promising to replace the ubiquitous Postman. I will not go into detail here on what is wrong with Postman - developers have their own (strong) opinions and the existence of so many API tools kind of proves this statement. Some nice articles I think are relevant:

https://apiexpert.medium.com/the-limitations-of-postman-bff619577a7b

https://club.ministryoftesting.com/t/postman-as-a-non-enterprise-tool-is-basically-dead/65177

I took a close look and tried to make a good analysis and inspection of some of these API tools. What I found is that most of them have a kind of narrow focus - they primarily focus on API testing as well as storing API collections, whether in the cloud, git repositories, or local files. However, I do think that this narrow focus approach kind of neglects the much broader scope of API management. You see, API management includes API design, API documentation, and API publishing.

A bit of a background on why I did this analysis: With my team, we built a catalog of more than 100 APIs and as you can imagine we had to really perfect our API management game. Well, as you can imagine this was difficult in this fragmented setup. Our team often had to rely on a patchwork of specialized tools, leading to inefficient processes and numerous challenges.

The Fragmentation Problem

API management is a multifaceted discipline - Therefore relying solely on tools that emphasize testing while neglecting other critical aspects (such as design, documentation, and publishing) can lead to several problems. Let's consider the following components of an API lifecycle:

• Design: Crafting the structure and behavior of APIs.
• Documentation: Creating clear, user-friendly guides and references for API consumers (both internal and external).
• Testing: Ensuring that the APIs function as expected under various cases and conditions.
• Publishing: Making the APIs accessible to external and internal users.
  • Monetizing: I have added monetizing as a subcategory here because it clearly addresses the need to be able to charge users for using APIs that have been published.

Each of these components is by itself crucial for the successful deployment and utilization of APIs. However, when teams use different tools for each of these tasks, (such as SwaggerHub for design, Confluence for documentation, ReadMe for user guides, Stoplight for collaboration, and endless copy-pasting of cURL commands on Slack,) the process can become disjointed and cumbersome.

I don't mean to say that these tools are bad or wrong. The opposite. I have used and loved almost all of them. The problem lies with the integration, their fitting into the big(ger) picture. But since we are on the topic, let's have a look at the different parts of the API lifecycle.

Overview of Tools by API Lifecycle Phase

Design Phase

Tools: SwaggerHub, Stoplight, Apicurio

• SwaggerHub
  • Pros:
    • Supports OpenAPI standards
    • Some collaborative features
    • Integrates with various CI/CD pipelines.
  • Cons:
    • Can be complex for beginners
• Stoplight
  • Pros:
    • Visual interface for designing APIs
    • Supports OpenAPI and JSON Schema
  • Cons: Limited offline capabilities
    • Some users have reported performance issues with large projects.
• Apicurio
  • Pros:
    • Open-source
    • Integrated with Red Hat's ecosystem
    • Strong version control.
  • Cons:
    • Steeper learning curve
    • Fewer features compared to commercial alternatives.

Documentation Phase

Popular Tools: Confluence, ReadMe, Slate

• Confluence
  • Pros:
    • Great for internal developer documentation
    • Integrates well with other Atlassian tools, and robust search functionality.
  • Cons:
    • Not specialized for API documentation, can be overkill for smaller teams.
• ReadMe
  • Pros:
    • Designed specifically for API documentation, easy to use.
    • Supports API key generation.
  • Cons:
    • Kind of expensive for small teams.
    • Limited customization options.
• Slate
  • Pros:
    • Open-source, clean, and responsive design, Markdown-based.
  • Cons:
    • Requires setup and hosting, less intuitive for non-technical users.

Testing Phase

Tools: Postman, Insomnia, Bruno, Karatelabs

• Postman
  • Pros:
    • Comprehensive testing features
    • Community support.
  • Cons:
    • Can be resource-intensive
    • Sort of many features/bloated
    • Many add-ons - Premium features can be expensive.
• Insomnia
  • Pros:
    • Lightweight, intuitive interface
    • Great tool for quick testing.
  • Cons:
    • Less feature-rich compared to Postman
    • Limited collaboration features.
• Bruno
  • Pros:
    • Local Collection Storage
    • Bru Markup Language
    • Git Collaboration
  • Cons:
    • Offline-Only Operation: Bruno operates strictly offline, prioritizing data privacy. Unlike other tools, there are no plans for cloud sync in Bruno, emphasizing the importance of keeping your data on your device.

Publishing Phase

Tools: Apigee, Kong, MuleSoft

• Apigee
  • Pros:
    • Comprehensive API management platform
    • Strong security features.
    • Analytics and monitoring.
  • Cons:
    • High cost
    • Can be complex to set up and manage.
• Kong
  • Pros:
    • Open-source
    • Highly customizable
    • Good plugin ecosystem
  • Cons:
    • Requires significant technical expertise
    • Less user-friendly interface.
• MuleSoft
  • Pros:
    • Robust integration capabilities
    • Supports a wide range of protocols
    • Strong enterprise features.
  • Cons:
    • Expensive
    • Can be overkill for smaller projects.

Monetising Phase

Tools: Rapid, API Layer

• Rapid
  • Pros (for API providers):
    • No barrier to add an API
  • Cons (for API consumers):
    • No Curation - Anyone can publish their API
    • Different subscriptions for using different APIs
• API Layer
  • Pros (for API providers):
    • No easy way to publish
  • Cons (for API consumers):
    • Different subscriptions for using different APIs

Challenges of Fragmented API Tooling

Despite the many pros for each tool, the main challenge I see is that ultimately companies need to use many of them at the same time for different purposes. The use of different tools for API management leads to several issues:

1. Broken Processes: When tools don't integrate seamlessly, the API-related workflows become disjointed. Information then has to be manually transferred between tools, increasing the risk of unwanted errors and omissions.
2. Confusion: Different team members may prefer or require different tools. Trying to accommodate these different needs can result in a lack of standardization. This diversity can cause confusion, especially when onboarding new team members or collaborating across departments.
3. Frustration: Inefficiencies and misunderstandings can lead to frustration among team members. Developers, QA specialists, Technical Writers, and API consumers often have different needs and priorities. A fragmented tooling environment fails to cater to these diverse requirements effectively.

The Need for Integrated API Management Tools

For API management to be truly effective, tools need to facilitate a (real) seamless collaboration and offer role-specific capabilities. An ideal API management tool should cater to the needs of various stakeholders, such as:

• QA Teams: Require robust testing features and easy access to all test cases and results.
• Developers: Need efficient design and debugging tools integrated with their workflow.
• API Consumers: Look for clear, comprehensive documentation and reliable API support.
• Technical Writers: Need intuitive documentation tools that can easily integrate with design and testing processes.

ApyHub: A Comprehensive Alternative

The inefficiencies mentioned above have been the main drivers for us to keep working on the ApyHub Platform. We started with the catalog, enabling API consumers to browse and discover APIs for their applications. Later, we built Fusion which focuses on building, testing, and documenting the APIs: We want to be a realistic and robust alternative to Postman, addressing the fragmentation problem by unifying the essential components of API management into a single platform. To give some context, we wanted Fusion to offer:

• Designing, Testing, and Documenting APIs all in one place: Fusion is an all in one tool/ecosystem that accommodates all the phases of the API lifecycle. Fusion can be used by developers to design and build awesome APIs, by Technical Writers to document them, and by QA teams to Test them. Finally, it can be used to publish the APIs both internally but also externally (with the option to monetize them).
• Real-Time Collaboration across all stages in the API lifecycle: Fusion allows multiple team members to work on API design, testing, and documentation simultaneously, ensuring everyone is on the same page.
• Modular API Design: Provides flexibility in designing APIs, accommodating various complexity levels and use cases.
• Self-Hosted Options: Ensures data ownership and security by allowing organizations to host Fusion on their own servers.
• Intuitive User Experience: Focuses on a user-friendly interface that simplifies complex tasks, making API management more intuitive and less frustrating.

Conclusion

The fragmentation of API tooling is a significant challenge for many teams, leading to inefficiencies and frustrations. By integrating design, documentation, testing, and publishing into a unified platform, Fusion offers a comprehensive solution that enhances collaboration, streamlines processes and caters to the needs of all stakeholders involved in API management. Adopting such an integrated tool can transform API management from a fragmented, inefficient process into a seamless, productive experience.