If you use non-nullable value types (e.g., enums) in web API models, you probably aren't getting the behavior you are expecting, both for required and for optional properties. I find it better to always use nullable value types.
When you enable nullable reference types for an existing Web API project, it changes how properties in request bodies are validated. This can easily break your application if you don't modify your models accordingly.
I already wrote about the potential dangers of using the IEnumerable interface in the past. But I recently encountered a bug related to it which I found worth sharing. It caused the exception filter in ASP.NET Core to not handle the exception thrown in the action method.
Just recently, I received a bug report for an ASP.NET Core Web API application I'm maintaining because of incorrectly rendered schema for a response in the Swagger UI. The culprit ended up being an old version of Swagger UI used by an old version of Swashbuckle.
In a recent blog post, I described how to add JWT authentication to an ASP.NET Core Web API project. This time I'm doing the same for a gRPC project. To test the authentication, I'm using similar Web API integration tests, with slightly modified setup to make them work with gRPC.
While preparing the sample project for my blog post about JWT authentication, I spent too much time troubleshooting an issue with failed authentication of calls from .http files in Visual Studio. It turned out to be caused by how Visual Studio handles redirects. I decided to check how Bruno and Postman behave in this scenario.
Although there's great support for JWT bearer authentication in ASP.NET Core, I had a hard time finding clear instructions on how to add it to an existing ASP.NET Core (Web API) project. In the end I decided to create my own sample project as the basis for discussing the ins and outs of JWT authentication.
I wrote a post about integration testing web APIs a while back. But when I wanted to use the same approach in a project with top-level statements, it wasn't immediately obvious to me how. While looking for a solution, I stumbled across some documentation for an even simpler approach.
The .NET Feature Management libraries are great for toggling the availability of ASP.NET Web API endpoints with feature flags. Unfortunately, such endpoints will still show up in the generated OpenAPI specification even when the feature flag is disabled. To hide them, you need to implement a custom filter for Swashbuckle.
By default, the OpenAPI specification created by Swashbuckle for ASP.NET Core web API doesn't include the descriptions for endpoints and models from XML comments. There are step-by-step instructions how to add them in the documentation, but even then there will be no descriptions for models from other assemblies.
GitHub Actions can be a good choice for deploying an ASP.NET Core application to an Azure Web App Service if you have the code in a GitHub repository. You can even generate the GitHub Actions workflow directly from the Azure Portal. However, if your solution is not very simple, the generated workflow may not work correctly.
In a previous blog post, I looked at integration testing of ASP.NET Core Web APIs. But often unit tests make more sense. So instead of checking the already serialized responses from the REST service, you would check the value returned by the controller action method before it is serialized into an HTTP response by the ASP.NET Core runtime.
I recently had an issue with optional route parameters in ASP.NET Core Web API not showing as such in the Open API specification generated by Swashbuckle. The most comprehensive source of information I could find on this issue was a blog post, which I used as a basis for further research.
An endpoint in my ASP.NET Core web API project suddenly started returning a truncated JSON response with a 200 response code. According to the logs, an exception was thrown, but for some reason the response code was not 500 as I would expect.
ASP.NET Core provides great support for integration testing of Web APIs. You can host the server in the test process and still make requests over HTTP. However, if your app reads its configuration from the appsetting.json file, you'll quickly find that the test server cannot find your regular configuration file.
Braintree's Hosted Fields offering is a great compromise between payment form customization and PCI SAQ A compliance requirements. Although it is not immediately evident from the documentation, the payment form can also easily be extended with custom data fields that your business might require. This post demonstrates how to do it in an ASP.NET Core application.
If you're used to the old ASP.NET, it's not all that obvious how to deploy an ASP.NET Core application to IIS. Although, there is documentation available for the process, I still struggled a bit, before I got everything working. This post contains the steps I had to take, so that I can simply follow them the next time. At least, until something changes again with one of the future releases.