I wanted a REST client whose workflow was not hard-coded

Most REST clients are excellent until the request succeeds.

Then the surrounding work begins: add a header based on the current environment, validate a response, extract a value, expose the operation to somebody who should not need to understand the raw request, or repeat the same five clicks tomorrow.

I kept seeing the same awkward choice:

• keep the workflow as tribal knowledge around a generic request;
• write a script that only its author understands; or
• build and maintain another internal web app.

I built BuildAPlugin to explore a fourth option: keep the request inside a local REST client, but make the client itself programmable.

A plugin should be inspectable

The extension format is ordinary JavaScript. A minimal plugin declares what it intends to use and returns the request or response it changes:

module.exports = {
  manifest: {
    id: "request-marker",
    name: "Request Marker",
    version: "1.0.0",
    priority: 100,
    permissions: ["requests.transform"]
  },

  beforeRequest: function(request) {
    request.headers = request.headers || {};
    request.headers["X-Plugin"] = "enabled";
    return request;
  }
};

Enter fullscreen mode Exit fullscreen mode

That explicit manifest matters. Extensibility becomes difficult to trust when behavior is invisible or when every extension implicitly receives the whole application.

Hooks are useful after the happy path

The request hook is only the beginning. A response hook can inspect a result and update focused parts of the rendered workspace:

module.exports = {
  manifest: {
    id: "response-status",
    name: "Response Status",
    version: "1.0.0",
    permissions: ["ui.transform"]
  },

  hooks: {
    afterResponse: function(ctx) {
      ctx.dollar("#responseStatus")
        .text("Status: " + ctx.response.statusCode);
      return ctx.response;
    }
  }
};

Enter fullscreen mode Exit fullscreen mode

This is where a generic API request can become a small operational tool. The raw request remains available, but the everyday user can get a button, a form, validation, or a purpose-built response view.

Keep local workflows local

The app starts as a desktop REST client for macOS, Windows, and Linux. Requests, variables, response inspection, Postman-style collection import/export, and plugin data do not require turning every workflow into a hosted service.

For workflows that are easier to express spatially, the same workspace includes a visual builder for connecting inputs, layout, logic, API actions, state, and device operations.

The design goal is not to replace code with boxes. It is to let each part of a workflow live at the level where it is easiest to understand.

The question I am testing

The interesting question is not whether another REST client can send a request. It is this:

What repeated API task deserves its own small interface, but does not deserve an entirely separate application?

I have published a 24-second product walkthrough showing the request, response, plugin menu, and visual builder:

BuildAPlugin is available here:

https://buildaplugin.com/download/?utm_source=devto&utm_medium=article&utm_campaign=channel_launch&utm_content=inspectable_plugins_launch

I would genuinely like examples of the repeated API workflows you would turn into focused tools first.