We review the open-source Postwoman project; a lean API request builder
API testing is of prime importance – few would underappreciate this step of the development process. As such, the availability of tools for testing, refining, and development is wide and ever-changing.
One new option is Postwoman. Postwoman is an interesting tool, as it eschews much of the weight of other solutions for efficiency and efficacy. While not intending to replace Postman, it presents an alternate, lighter offering with similar efficiency. Today, we’re going to look at Postwoman, and see what makes it special. We’ll take a look at its feature set in comparison to other API request builders, and see what sort of use case would be most appropriate for either.
Before diving into Postwoman, let’s first discuss Postman. While Postwoman wasn’t designed to replace Postman, it was inspired in part by what Postman does. Postman is fundamentally an API tool that is built for testing, building, and modifying APIs.
Postman is used quite ubiquitously as a tool for developing reliable services, as its testing suite is quite robust. In addition to that use, Postman has a collection of very specific builds designed around specific use cases. These include builds focused on testing automation, developer onboarding design, and more.
Because Postman offers a wide variety of builds, it has become very common in API circles. Offering a Postman Collection alongside API reference is almost a standard practice. It’s a great tool, and its many integrations make it available to most developers. That being said, there are some concerns with Postman.
One such concern with Postman is the fact that it can be quite heavy. Creator Liyas Thomas considered Postman as a tool for one of the tasks under Zartek, a startup in Kerala, India. The task was simple: create an API integrated with an old project that Zartek wanted to bring into service. When looking into Postman, however, Thomas was dissatisfied with the idea of running yet another Electron build on her already-taxed PC – running a low power system meant that additional load would cost time and efficiency.
As she looked at other API request builders, Thomas began to feel that they all lacked significant qualities she desired. Chief among these was simplicity, minimalism, and efficiency. Even though these solutions were incredibly powerful, this power almost always came with a cost. Whether that cost was in terms of monetary expense (which, when scaled up, could quickly become irksome and expensive) or in terms of hardware cost (especially concerning processing demands), for Thomas, the solutions on offer demanded too much for what they delivered.
From this, Thomas struck out to build Postwoman. Postwoman was designed to have some very specific features:
- Postwoman had to be open source and free;
- Postwoman had to run online, alleviating the processor demand made upon local machines running the solution;
- It had to have ample multi-platform and multi-device support;
- The solution had to be accessible from anywhere, detached from local restrictions on hardware or locale.
With that in mind, let’s look at some key features, and what use cases they might be appropriate for.
Postwoman is first and foremost a testing tool. Because of this, Postwoman has ample verbiage, supporting
PATCH, with more planned in the short term. On top of this basic functionality, Postwoman also supports Authentication, allowing for greater security in testing environments. The support for Parameters and Request Bodies enables greater testing possibilities, especially for more complex offerings. This is actually a key feature, as simple testing solutions often necessarily mean simple ability to test; in this case, Postwoman is simple while still being feature-rich.
After initial development, several updates were added to extend functionality. Support for request history, Web Sockets, and raw input allowed for substantially more extensibility. Feature additions like response status coloration, theme customization, and response copy to clipboard mirrored this functionality boost in the user experience of Postwoman.
Postwoman Use Case
As with most custom tools, the use case here is pretty clearly stated. For certain teams, the simple fact is that some tools too expensive to run. This expense can come in the form of monetary expenditure or hardware requirements, but at the end of the day, simple testing with a full feature set is a highly desired solution. In this case, Postwoman is an apt solution and serves a need for developers who want to perform API call tests without the hardware expense that comes with those equally more robust and demanding solutions.
Postwoman is an alternative to Postman, even if it’s not meant to be a one-to-one replacement. While it may not be as fully-featured as Postman, that’s somewhat the point; Postwoman is lean, effective, and efficient, eschewing much of the bloat of other alternatives in favor of an “operate everywhere efficiently” approach.
That being said, it’s really a matter of requirement. If the requirement at hand is one of high extensibility or demand, then Postman and other testing alternatives are certainly a good suggestion. If efficiency, efficacy in lean programming, and free, open-source functionality is a requirement, then Postwoman is absolutely a wonderful choice.
Have you used Postwoman? What are your thoughts on it? Please let us know in the comments below!