For a long time, Azure Key Vault was not following the same API versioning scheme as other Azure services. If you’ve used the Azure Key Vault Emulator ever since I forked the old (very limited) code, You’ll have noticed that the APIs the emulator implemented were from the v7.4 definition. After that, Microsoft published a v7.5 and v7.6 version. For example, v7.6 introduced an API for getting key attestation.

Sometime last year, they must have decided to align API versions with other Azure services, and they switched to the date-based versioning. The first new such version they introduced was 2025-07-01, and one of the new things they added was the outContentType parameter on the Get Secret APIs.

The Utf8JsonReader struct was introduced years ago with .Net Core as a built-in alternative for reading JSON documents one token at a time as opposed to using external libraries or reading entire documents into memory at once. It was design to be a forward-only API outperforming other similar readers like those from the Newtonsoft.Json libraries. The performance however comes at the cost of convenience and ease-of-use, at least in some situations.

Every now and then I have to build some browser based application for which I often end up using an SPA (single page application) approach. For instance, combining Vite with React and React Router in my opinion is a fast approach to get something ready quick. Adding MUI on top for a nice-looking experience can help too.

Then comes the time when this needs to be hosted somewhere, such that browsers can download the static assets linked from the index.html at the root to make the application availble for others to use. Using your everyday hosting provider can be simple and straightforward, and very often a good enough choice. Those providers usually have some offerings for static web hosting (which an SPA basically is), which they build in their infrastructure through virtual hosts through Apache HTTP Server or nginx or something like that. Those servers do the trick, and they can be configured through - sometimes very complicated - configuration settings. Sometimes I use this sort of thing too. So far so good.

In my previous post about local development using the Azure Key Vault Emulator I briefly mentioned my own fork of the emulator to address some missing APIs. One thing I had planned to change in the emulator for a while was how the REST API endpoints exposed by the emulator are created. The old approach (from which I forked) manually crafted the REST APIs including the models needed. That’s been a thorn in my flesh from the first moment I saw it, and I knew that I wanted to fix that. After all, Microsoft has official Open API specs for the Azure Key Vault REST APIs, so why not use those?

One problem you’ll sometimes encounter when working with cloud services from AWS, Azure or Google cloud is that developing locally can be made more difficult when working with services that do not have a standardized interface with an implementation readily available for local installation. For instance, when working with a pub/sub system that is compatible with Kafka you can just install a minimal Kafka cluster locally and all is good. But what to do when the APIs offered by the service you need are not standardized? That’s when emulators come in. In the rest of this post I’m going to focus on Azure, since that’s what I’m working with most often.