Last year, I published The Little ASP.NET Core Book, a friendly and free introduction to web programming. The book is published under a Creative Commons license, and the source is freely available on Github.

People from all over the world have read it to learn how to build modern web applications, or just to brush up on what’s new in ASP.NET Core 2.0.

Today, I’m releasing an updated version that adds brand-new content and incorporates many suggestions from readers. Keep reading to learn more, or download a copy!

Most ASP.NET developers are familiar with the [RequireHttps] attribute that forces HTTPS connections for a particular route or controller. However, if you’re building an API in ASP.NET Core, the official documentation includes this warning:

Do not use RequireHttpsAttribute on Web APIs that receive sensitive information. RequireHttpsAttribute uses HTTP status codes to redirect browsers from HTTP to HTTPS. API clients may not understand or obey redirects from HTTP to HTTPS.

It’s important to use HTTPS for both your browser applications and APIs, but [RequireHttps] only focuses on the former. How should you enforce HTTPS for APIs?

The OAuth 2.0 and OpenID Connect protocols are used all over the web. Big platforms like Google and Facebook use them extensively for both authorization and social login (the ubiquitous Facebook Login button). These protocols are powerful, but unfortunately they aren’t always easy to use.

If you’ve ever struggled to set up OAuth or OpenID Connect, you’re not alone! I got so tired of fighting with bad requests and cryptic responses that I decided to write a tool to make it easier.

It’s been over two months since I released the Little ASP.NET Core Book, and I’ve been blown away by the response!

“This looks great. I’ve been learning ASP.NET Core with scattered resources around the web, and your book seems to explain everything in a simple way.” - aesthetics1 on HackerNews

I’ve been excited to see people downloading and tweeting about the book, but I’m even more excited to see people forking the content, adding suggestions, and translating it to other languages.

Today I’m excited to release my side project for the last few months: the Little ASP.NET Core Book!

This free book is a short introduction to the ASP.NET Core 2.0 web framework. If you’ve never built apps in C# or ASP.NET (or even if you have!), this book will teach you the basics of building modern, fast web applications using ASP.NET Core.

Get a free copy on the book page!

The console (terminal) on Windows has come a long way since command.com. PowerShell might seem weird at first if you’re used to bash on *nix, but it’s grown into a very powerful console and scripting tool.

Over the years, I’ve gathered a list of my favorite plugins and tweaks to make PowerShell and the console even better. In this post, I’ll show you how to customize PowerShell on Windows 10 for an awesome console experience.

I’m a big fan of the async/await pattern introduced in C#. It’s one of the best ways to reason about asynchronous code, and it’s spreading to Python and JavaScript too.

Every once in a while, I need to run some async code in a .NET command-line application, but the Console Application template in Visual Studio makes it annoyingly difficult to do.

A web API that returns JSON responses should be expected to return errors or exceptions as JSON messages, too. You can use exception filters in ASP.NET Core MVC to trap and serialize exceptions that occur within MVC. However, if an exception is thrown before (or after) the MVC pipeline, it won’t be handled by the filter and the client will get an ugly error message (or a 500 Internal Server Error).

A more universal solution that can trap and serialize any exception that happens during a request is an exception handling middleware component. The syntax is a little different than an exception filter, but the principle is the same.

In this post, I’ll show you how to write error handling middleware and how to extend it with custom behavior.

JSON is by far the most popular response format for APIs today. It’s not hard to see why: it’s easy for both humans and machines to read. Virtually all platforms and devices can read and write JSON, making it nearly as ubiquitous as HTML. JSON is unstructured and “squishy”, which makes it easy to model dynamic responses. (Maybe a little too easy.)

If you’re building an API, especially one with more than a few endpoints, you’ll likely want to adopt a schema or pattern for your responses. This could be as simple as one or two common response properties, or it could be a complex message envelope. Unlike XML, JSON doesn’t have a built-in way of defining a document schema (the downside of being unstructured and squishy).

There are a few popular ways to add schemas to JSON, but they all have drawbacks. In this post, I’ll examine some of those drawbacks, and show you how to use Ion to create intuitive, beautiful REST APIs.

HATEOAS, or Hypermedia as the Engine of Application State, is a complicated-sounding term for a simple idea:

A client interacts with a REST API entirely through the responses provided dynamically by the server.

Put even more simply:

You shouldn’t need any documentation or out-of-band information to use a REST API.

This may sound odd, because the first stop for any developer working with a new API is the documentation. How could you interact with an unfamiliar API without any out-of-band information?