The design process for this project spans several years and includes user research and a futuristic vision of API design and development of the future.
As an author of another developer tool for API testing, the Advanced REST Client, I spent years talking to API developers. I was listening to the community's voice that would suggest the best approach to API development. I remember very well a call I had with an API developer who was describing their API development process. It all went down to a single statement that they need a clear definition of standards that would help them build consistent and compliant with the organization standards APIs. It takes me to another product I worked on at MuleSoft - the Domain Modeling Initiative. It is described better in another article on my portfolio page. Still, we research how we can build consistent standards for API development through data modeling.
These two events prompted me to design a new experience for API design and development. Below I explain each part of the ecosystem.
When you begin your journey with the API Cloud, you'll enter a 360 view of your team's work. The platform lets you organize your work however you please with a filesystem-like structure. Each file represents a user's completed work, with one file defining an API and another containing HTTP queries for that API. The suite includes different types of work that correspond to various stages of API development.
This design is an improvement over traditional API platforms that have multiple apps, each with its own backend for storing data. Users must learn and understand each app before they can effectively use the platform. Feedback from product forums, often open to the public, has revealed that this approach is less efficient, especially for newer users. By placing user-generated data in a single location that the user can structure as they choose, we can create a more user-friendly design.
As the creator of Advanced REST Client, I've spent years exploring various designs and perspectives on how developers can best use an API. While Postman and Swagger are just a few of the many available tools, I discovered that most of them follow the basic layout that I created in 2012 for the original version of my REST client. This consists of an HTTP method and URL line, followed by a tabbed view of specialized editors for headers, query parameters, and body. Nowadays, there are other editors for assertions, authorization, and HTTP engine configuration.
I've examined many of the tools on the market for their UI composition, user workflows, and functional layers. Some apps, like Postman, are swiss-army-knife applications that handle everything in a single frame. Others take a more platform-based approach, separating these functions into different specialized apps. However, my project principle dictates that API development cannot rely on a single tool, as different aspects of API development require various specialized tools. Therefore, the API Cloud apps focus on developer workflows rather than single-app functionality.
The API Client is a tool that helps developers create a library of HTTP calls, which allows them to structure their work with an API. This approach works for both API developers who code the API and API consumers who can use these libraries to learn how to consume the API. It supplements the API specification that describes the API structure.
In the API Cloud ecosystem, schemas are essential building blocks that define data shapes for API design and consumption. They are created by a specialized application and differ from traditional data modeling. API Client schemas include attributes like indexes, keys, and read/write-only fields and can be used in workflows by other applications.
I designed this system to support new use cases like Protocol Buffers, which has been requested by Advanced REST Client users. By defining abstract data shapes with API targeting metadata, the ecosystem can translate them into specific formats such as JSON, XML, or Protocol Buffers.
For maximum scalability, no-code solutions are the way to go. To create a flexible interface without writing any code, I carefully analyzed various approaches to API testing and devised a UI that would suit most use cases. After studying popular tools and libraries, I came up with a simple yet powerful interface for defining HTTP tests.
The tests are defined using a syntax that's already familiar to many developers around the world - the Assert library. This library is commonly used for conducting unit tests of code. Each block of the test represents a step in the flow, starting with the data (response header, status code, and body) and proceeding through various transformations and assertions. This means the user can easily extract any information from the HTTP response and perform assertions in a way that's already familiar to them.
Within the ecosystem, there are various applications available, including those for schema design, API monitoring, and innovative API definition. However, these applications require significant time and effort to design and develop, making it challenging for a single person to undertake such a large project alone. As a result, I am seeking support from organizations that share my vision and have the necessary resources to collaborate with me in bringing it to fruition. If you are interested in helping, please do not hesitate to contact me.
