It's always the "it depends" kind of answer.
In bigger companies, you have teams dedicated to API governance, whatever they say, it's how it's done. In early-stage startups, you have full-stack folks doing end-to-end design, test, integrate with UI, document, etc. The trickiest ones are the ones that are in between these two stages. It's where it gets messy, and you MUST have something in place to serve as an API contract. Swagger dominates that, imho, Postman collections and docs are used a bit differently in my experience.
I'm helping build https://voiden.md which serves as a unified place for API spec, test, and documentation, but there are also plenty of API tools that focus solely on endpoint execution.
A little bit of feedback, I could barely read any of the text in the interface as the contrast is almost zero and the font is unbelievably small. So I tried Cmd+ to zoom the interface, but nothing happened, so I tried Cmd, to open the settings to see if there was a zoom level or contrast setting, nothing happened. I like the idea of it, but it's totally unusable.
Voiden looks really promising, so I installed it to get started, and here's my hot takes so far before even using it.
* The text is tiny for my old eyes. I figured there's probably a setting for it and hit Cmd-, and found there's no settings UI whatsoever. No keyboard shortcut either it seems, and no help menu either, so no searching for "keyboard" with Shift-Cmd-/
* .void files may be markdown, but no markdown editor will recognize it as such. Maybe support .void.md as well. I also couldn't find any way to edit the markdown source of a .void file from voiden, which is a bit ironic for a tool that loudly advertises the markdown format as a central feature.
* Could there be a block that expands into the full URL of the request and parameters above it (or perhaps as args)? How about another that renders as a cURL command, which would cover POST/PUT/PATCH requests nicely too. My API documentation always has cURL request examples and I detest writing them by hand.
* While I'm suggesting blocks, one that renders the response headers/body to the preceding request would also be handy. It should support a placeholder response that gets replaced when the request is actually run (and perhaps a "save" button to persist it in the markdown). Responses get long, so maybe have a max-height for the block and make it scrollable
I'm actually really excited about Voiden and hope these can be addressed. It has a similar feel to Jetbrains' .http format, but an evolutionary leap beyond it. It also feels really raw and unfinished.
Hi, thx for the feedback!
Testing the settings (including different themes and font sizes as we speak).
Some tweaks are been made on the responses side as well.
As per the rest of your comments, some of these things have been discussed or touched upon, others have been just added to the discussion board :)
I'm helping build Voiden: https://voiden.md
But am thinking of a LOT these days, really, saw a bunch of interesting APIs on https://apyhub.com/catalog recently, so might go on and tackle a few of these.
I mean, IF the API is primarily tailored for UI presentation, there's already a text/html that you can use. I don't see the real problem here. Unless it's a type of API that has multiple purposes. In which case you got to tailor the response/presentation based on the needs.
Either way, the time needed to build a HTML elements will be eventually spent somewhere, on the server or on the client side. Server provides you with the data, you pick the form in which it is sent, and then work around the presentation layer.
I'm helping up the team behind https://voiden.md so I can tell you, it's easy to present the HTML even in the API clients, let alone the website itself.
A TL;DR of it is that for teams behind APIs, building, documenting, and testing APIs feels all over the place nowadays. It's a pain, it wastes time, causes errors, and frustrates everyone involved.
This post dives into why API tooling is such a headache, why the industry keeps making it worse, and how Voiden attempts to make life easier for developers.
Totally agree on this. There are things that belong in cloud, even a 3rd party one. Not everyone has a luxury of self-hosting. But keeping API secrets in any 3rd party cloud is just insane imho.
Something internal, or did you publish it?
What would you say is the most important stuff to you? Only simple API testing, or you gotta take care of the specing and documenting it as well.
It’s on github buried in a much larger personal project that I have not shown anybody.
I was once a JS developer for an eternity but now I do enterprise API management in a highly restricted environment. I just needed something reliable and postman was not always reliable.
I'm helping build https://voiden.md/ We just dropped a major beta, FOSSing it by the end of the year.