Nightingale REST Client is a Windows API client that went open source in 2024

A decade of hobby development, then an open source dump

Nightingale REST Client is described as a modern, resource efficient REST API client for Windows, and it is written in C# with XAML, WinUI and UWP, targeting Windows 10 and Windows 11. The homepage is nightingale.rest, and the app is distributed through the Microsoft Store.

The reason it is interesting is the history, which the README tells without flinching. Development started nearly a decade prior as a hobby project, and when the author started there were only a couple of years of C# experience behind him. The source was released on January 19, 2024, and the README says plainly that as developers browse the code they will see that it is messy, disorganised and poorly structured, and that this is why.

The stated reason for open sourcing is that a tool like Nightingale is perfectly situated to be supported by the open source community, a tool for developers built by developers, and that open sourcing the app had always been part of the plan but his lack of experience in the early days held it back.

The goal is stated as well: to improve the code to the same level of code quality as Ambie, another project by the same organisation, jenius-apps.

This is a rare kind of repository to encounter. It is not a library, and it is not presented as a finished product. It is a working application, thrown open with an honest warning attached.

What changes for users when a Windows app becomes open source

The README has a short section on what changes for users now that the app is open source, and the answers are practical rather than ideological.

More bugs fixed. More opportunities to contribute. And more updates, with a direct instruction to make sure auto-updates are turned on.

That third point is a real operational note. The Microsoft Store version handles its own updates, so a user who turns auto-updates off will keep running whatever build was installed at the time, which for a project in this state means an old build with old bugs.

The build side of the story is the roadmap section, and it lists the work in order of scale. First comes a lot of refactoring to bring Nightingale up to speed in the modern world: migrating to a better MVVM system, migrating to the latest version of C#, and restructuring the repository so that feature development becomes easier and faster. In parallel, bug fixes and minor changes from the community are welcomed. And shortly after that work, version 5 is planned.

So the shape of the project is clear. It is a long refactoring followed by a major version, with community patches accepted in the meantime. Anyone evaluating it for adoption should read that list as a statement about what the code looks like now.

Building it needs a commercial control library

The build instructions are the practical part of the README, and they carry a TODO comment saying the steps need further improvement. What they describe is a Visual Studio build on Windows, and the first step is not about Nightingale at all:

1. Retrieve an evaluation copy of Actipro's control library from here: https://www.actiprosoftware.com/download/controls/universal.
2. After filling out the form, downloading their package, and installing their SDK, you will need to update the SDK reference in the Nightingale project in Visual Studio.

After that, the remaining steps are the standard ones. Install any other missing components that Visual Studio reports, set Package as the default startup app, change the debug architecture to x64, and press F5 to build and debug the app.

The Actipro dependency is the part that shapes who can build this. It is a commercial UI control library for Windows, it requires a form and a download before the SDK is usable, and the project reference has to be repointed to the locally installed SDK. That is a real friction point for a contributor who expected to clone and press F5.

It also means the source is not buildable with no external dependency at all, which matters for anyone auditing the code, since you cannot even compile it without first obtaining a third party binary.

What the repository contains beyond the source

The top level of the repository is small and says something about the shape of the project. There is a src directory with the application code, a builds directory, a docs directory, an images directory, a screenshots directory, and a .github directory for the workflows.

Alongside the code there are the documents a shipped desktop app needs. A changelog.md records the changes, privacypolicy.md and termsofuse.md are present, and LICENSE.txt carries the licence.

The repository is MIT licensed, which is a permissive choice for a commercial application whose author works for Microsoft and whose distribution channel is the Microsoft Store. Any specific question about how the licence applies to a particular use belongs with your own counsel.

The screenshots and images directories exist because the README embeds a hero image and because the Microsoft Store listing needs artwork, so they are part of the publishing pipeline rather than documentation of the source.

A client that predates the current Windows app model

The topic tags describe the technical envelope: csharp, dotnet, nightingale-rest-client, restapi, uwp, windows10, windows11, winui, xaml.

Reading those together explains a lot about the code the author describes as messy. The project grew up as a UWP application, with the WinUI and XAML layers on top, and it targets both Windows 10 and Windows 11. That is a stack with more than one rendering model and more than one packaging story in it, and the planned work mentions moving to a better MVVM system and to the latest version of C#.

The MVVM point is the interesting one. A REST client is a natural fit for a clean view model structure, because a request builder, a response viewer and a saved request list are all classic separated concerns. A decade of hobby iteration on a UI of that shape tends to accumulate bindings, code behind and ad hoc state, which is exactly what a migration to a better MVVM system is meant to untangle.

The app is also described as resource efficient, which for a REST client means a lightweight window rather than a browser with an API tab. On Windows, where the default answer to an API request is often to open Edge, a small native client with saved history and a response viewer has a real niche.

Releases stopped in 2024 while the code kept moving

The tag history is short and the gaps are informative. v4.4.3 was released on 2024-03-14, v4.4.2 on 2024-01-20, and v4.4.1 on 2021-08-27. So two of the three most recent tags sit within two months of each other in early 2024, and before that there is a gap of about two and a half years.

That pattern fits the story in the README. The 2021 release was the previous shipped version, and the January 2024 release was the one that came with the open sourcing, followed by a patch in March 2024.

The repository itself is not archived and the last push was on 2026-07-02, so commits are still landing on the main branch. But there is no newer tag than v4.4.3, and no sign of a version 5 build.

For a user, the practical reading is that the Microsoft Store build and the tagged source are close in age, while the repository contains work beyond both. For a contributor, the state is a codebase mid-refactor with no release train attached to it yet, which is a good description of the project and also the main risk of picking it up.

Editorial conclusion

Nightingale suits a Windows developer who wants a native REST client from the Microsoft Store and is willing to read and fix the code rather than just use the app, since the project is explicitly inviting bug fixes while the refactoring proceeds. It is the wrong choice for a team that needs a maintained codebase today, because the newest tagged release is v4.4.3 from 2024-03-14 and version 5 is described as work still to start. Before building it, get the Actipro evaluation package and point the project at that SDK reference in Visual Studio, and read the repository layout in src/ before you plan any contribution.

Frequently asked questions

Official sources

1. jenius-apps/nightingale-rest-api-client on GitHub
2. License: MIT
3. Project website
4. README
5. Releases