Noodle: a terminal REST client where every request is a readable YAML file you version in Git
A delicious REST client for your terminal
At a glance
- What is it?
- Noodle is an Apache-2.0 terminal REST client that stores each request as a readable YAML file beside the code it tests. It offers a TUI, a CLI and a runner, so the same collections serve interactive work, scripts and coding agents.
- Who is it for?
- Use Noodle if you want your HTTP requests to live as readable YAML files versioned in Git beside the code they test, usable from a keyboard-first TUI, a CLI, a runner and coding agents from one representation: the file-first model with shared assertions and captures is its real strength.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
HTTP requests as versioned files, not a GUI database
Noodle is an open-source terminal REST client whose defining choice is that every request is a readable YAML file. The README's framing is files first: you write, send, inspect and automate HTTP requests from files that live beside the code they exercise, ready for the TUI, the CLI, scripts and coding agents.
The user is a developer who wants an API client that fits a code workflow rather than a separate GUI app with its own opaque storage. Because each request is a plain YAML file, you edit it in Noodle or your own editor, review it in Git alongside the code, and keep collections versioned with the project. That is the opposite of a GUI client that hides collections in a binary store or a cloud account.
What makes it more than a curl wrapper is that the same file-based collections drive four surfaces: a keyboard-first TUI for interactive work, a CLI for scripting, a collection runner, and coding agents that can read and run the files. It is Apache-2.0, and the README leads with fast by default, made to review, ready to automate, which is a fair summary of the file-first stance.
One readable file, four ways to run it
The format is deliberately plain. A request is YAML with a name, method, url, path params, headers and so on, so it reads like configuration rather than code, and the README's example is a `GET $base_url/users/:userId` with a typed path param. Because it is text, it diffs cleanly in Git, which is the whole point: a change to an API request shows up in review like any other code change.
The interactive side is a full workspace. The README describes composing URLs, parameters, headers, authentication and bodies from a keyboard-first TUI, then inspecting the body, headers, cookies, status, timing and network timeline in the same place. Requests carry Assert and Capture tabs, editing response checks and extracted values as structured rows with per-row checkboxes, so a request can validate its response and capture values for later requests, and disabled declarations stay in the file but are skipped.
That Assert and Capture design is what lets the same files serve automation: the collection runner and CLI runs honor the same checks, so a request you built interactively becomes a test you run in CI without rewriting it. The manual-send behavior using a fresh scope each time is a thoughtful detail that keeps interactive experimentation from leaking state into automated runs.
Installing and creating a collection
Installation is a single script. The README's install line is:
curl -LsSf https://noodlerest.dev/install.sh | shwith a documentation page listing every other installation option. Creating and opening a collection is a short CLI sequence the README gives directly:
noodle collection create my-api
noodle request create users/get \
--url https://api.example.com/users/42 \
--collection ./my-api
noodle --collection ./my-api`noodle collection create` makes the collection, `noodle request create` adds a request as a YAML file, and `noodle --collection ./my-api` opens the TUI on it. Because the collection is just a directory of YAML files under `./my-api`, you can equally create or edit requests in your own editor and commit them to the repository.
That CLI-and-files symmetry is the practical heart of Noodle: everything you can do in the TUI produces or consumes the same files the CLI operates on, so interactive exploration, scripted runs and version control all act on one representation. There is no export step and no separate sync, because the files are the source of truth.
The limitations: terminal-first and a young format
The honest limitation is that Noodle is a terminal tool with a keyboard-first TUI, which is a strength for developers who live in the terminal and a barrier for those who prefer a graphical client with rich visual response rendering. It inspects bodies, headers, timing and a network timeline in the terminal, which is capable, but it is not a graphical app, and that is a deliberate audience choice rather than a gap.
The file-first model also means adopting Noodle's YAML schema. That schema is readable and Git-friendly, but it is Noodle's format, so collections are portable as text yet tied to Noodle's conventions for path params, assertions and captures. For a team standardizing on it that is fine; for someone who wants to move collections between many clients, the format is a commitment.
As an actively developed open-source client, its ecosystem and integrations are younger than long-established API clients, so features that a mature GUI client accumulated over years may not all be present. The trade is that Noodle's core, files you version and run everywhere, is exactly what those older clients make hard, so the choice is between breadth of features and a clean, reviewable, automatable file model.
Against a GUI API client or raw curl
The alternatives are a graphical API client and raw curl or httpie. A GUI client offers rich visual editing and response rendering but typically stores collections in its own database or cloud account, which does not version cleanly in Git and couples your API work to that app. Raw curl is fully text and scriptable but has no collections, no interactive inspection, and no built-in assertions or captures.
Noodle's difference is that it combines the reviewability of text, each request a YAML file in Git, with the ergonomics of a real client, a TUI for composing and inspecting, plus assertions, captures and a runner that automation and agents share. The cost is the terminal-first interface and the commitment to its format. Choose a GUI client when you want rich visual editing and do not mind opaque storage. Choose raw curl for one-off requests with no structure. Choose Noodle when you want your API requests to live as versioned files beside your code, usable interactively, in scripts, in CI and by coding agents from one representation.
Apache-2.0, script-based updates, and where to start
Noodle is Apache-2.0, so it can be used, forked and adapted commercially with attribution and carries the patent grant, which suits a developer tool teams may want to standardize on. Because collections are plain YAML files in your repository, they are yours regardless of the client's future, which is a durability advantage over a client that locks collections in its own store.
Updates come through the install script and the documented installation options, and since collections are files, upgrading the client does not risk your data. The README points to a website and docs for the full workflow, and a SECURITY.md indicates the project takes the handling of requests, which can carry credentials, seriously.
The concrete first step is to create a real collection and put it under version control: run the install script, `noodle collection create` for one of your APIs, add a couple of requests with `noodle request create`, and commit the resulting YAML files so you can see how cleanly they diff. Add an Assert to one request and run it through the CLI to confirm the same file serves both interactive and automated use, since that shared representation is the reason to choose Noodle over a GUI client whose collections do not live in your repository.
Editorial conclusion
Use Noodle if you want your HTTP requests to live as readable YAML files versioned in Git beside the code they test, usable from a keyboard-first TUI, a CLI, a runner and coding agents from one representation: the file-first model with shared assertions and captures is its real strength. It is the wrong choice if you prefer a graphical client with rich visual response rendering, or if you need to move collections freely between many clients, since you adopt Noodle's YAML format. Start by installing via the script, running noodle collection create for a real API, committing the request files to Git to see them diff, and adding an Assert you run through the CLI to confirm one file serves both interactive and automated use.
Frequently asked questions
How does Noodle store requests?
The README says every request is a readable YAML file with fields like name, method, url, path params and headers. You edit it in Noodle or your own editor, review it in Git, and keep collections versioned beside the code they exercise.
How do I install Noodle?
The README's install command is curl -LsSf https://noodlerest.dev/install.sh | sh, with a documentation page listing other installation options. You then create a collection with noodle collection create and open it with noodle --collection.
Can Noodle run automated checks on responses?
Yes. The README describes per-request Assert and Capture tabs that edit response checks and extracted values as structured rows, honored by manual sends, the collection Runner and CLI runs, so the same files serve interactive work and automation.
Community notes