Hello! My name is Kevin Dockx, and welcome to Building Your First API with ASP.NET Core. In this course, you will learn how to build an API with ASP.NET Core that connects to a database via Entity Framework Core. You will get there by covering major topics like getting resources from services and manipulating them, the built-in dependency injection system & logger, working with different environments, configuration files and middleware, and Entity Framework Core related features like working with migrations and seeding the database.
By the end of this course, you will be able to build an API from scratch with ASP.NET Core.
Before you begin, make sure you are already familiar with C#.
I hope you’ll join me, and I look forward to helping you on your learning journey here at Pluralsight.
Course Overview Hi, I'm Kevin. Welcome to this Pluralsight course, Building a RESTful API with ASP. NET Core. I'm a solution architect focused on APIs and security and a Microsoft MVP. Building an API is one thing, building a RESTful API is something different. In this course you'll learn how to do that with ASP. NET Core. We'll look into how we can correctly interact with our API by using the correct HTTP methods and status codes, getting, updating, creating, and deleting resources. Learning about method safety and item potency will help us choose the correct approach for these different use cases. We'll also look into some less obvious cases and principals, like creating a list of resources in one go and upserting. We'll cover validation and logging as well, as when we're creating or updating something we want to ensure the input is valid, and if it isn't, we'll want to log that. We'll also cover common functionality RESTful APIs expose these days, like paging, sorting, filtering, data shaping, and so on. But we won't stop there. We're going to ensure our API is HATEOAS-enabled, so hypermedia will drive application state. It's one of those constraints RESTful architecture has that tends to separate truly RESTful APIs from run of the mill web APIs. We'll also learn how to correctly use media types and we'll look into versioning, caching, and handling concurrency. We'll end with a module on protecting and documenting the API. In the end, we'll have built an API with level 3 maturity, which is the highest possible level for APIs.
Introducing REST Hi there, and welcome to the Building a RESTful API with ASP. NET Core course, at Pluralsight. I'm Kevin, and I'll guide you through the rest of this course. This is the first module in which we'll introduce REST. REST is, and has been for a few years, all over the place, or at least so it seems, because a lot of APIs that are called RESTful aren't really RESTful. We'll notice why that's the case very quickly, but we'll start out with the course prerequisites and tooling. After that, we'll introduce REST and we'll look at the constraints a RESTful system must adhere to to be RESTful. And then, we'll learn about the Richardson Maturity Model. That's a model that describes the maturity of an API, and, in a way, to what degree it conforms to REST. It's an interesting model as it helps us think about how APIs used to be built, and still are in some applications, and how that can be improved upon with REST. And after that, we'll look at how we can position ASP. NET Core and the MVC pattern for building RESTful APIs. And we'll immediately dive into the first demo in which we'll inspect the starter solution. So, as you noticed this module is mostly theoretical, but I promise it'll be the longest stretch of slides without code for the rest of the course. Nevertheless, it's a pretty important module. What we'll learn here will come back in all the other modules of this course. Let's start out with the prerequisites.
Getting Resources Hi there and welcome to the Getting Resources module from the Building RESTful API with ASP. NET Core course at Pluralsight. My name is Kevin and I'll guide you through this module. First we'll learn about the outer facing contract, i. e. how are we going to design our resource URIs, allow the HTTP methods and payloads for our API? Once we know that, we'll start implementing it by getting resources, both single and collection resources. We'll also learn how to work with parent/child relationships. While doing this, we will encounter concepts that are essential to how we build RESTful APIs with ASP. NET Core. We'll cover HTTP methods and routing. We'll learn what status codes are why they are so important. And we'll learn about faults and errors and what the difference between these is. Lastly, we'll learn about content negotiation, which allows a consumer of the API to choose the format of the resource for presentation, if the API supports it. A lot of interesting stuff coming up, so let's dive in with structuring our outward facing contract.
Creating and Deleting Resources Hello, and welcome to the Creating and Deleting Resources module from the Building RESTful API with ASP. NET Core course at Pluralsight. My name is Kevin, and I'll guide you through this module. We now know how to get data from our API in a RESTful manner. Up next, we continue with implementing the outer-facing contract. We'll create a single resource, a child resource, and we'll learn what we can do if we want to create a resource and its children in one go, but we'll also cover a not so obvious case that often raises a few questions on how to do it, creating a list of resources in one go. Creating resources means using the content-type header to signify the media type of the request body, as we learned at the end of the previous module. We learn how to use additional content types for input together with input formatters. After that, we learn about deleting resources, we'll delete a single resource, a resource and related resources, and we'll look into whether or not deleting a collection resource is a good idea. But before that, we must talk about two principles that will help us understand why specific methods should be used for certain actions, method safety and method idempotency. Let's look into that.
Updating Resources Hi, and welcome to the Updating Resources module of the Building a RESTful API with ASP. NET Core course at Pluralsight. I'm Kevin, and I'll guide you through this module. In this module, we'll dive into updating resources, again continuing to implement our outer-facing contract. We know from the HTTP methods clip in the second module that there's two ways to update, put for full updates and patch for partial updates. We'll cover both in this module. But there's more, there's an in between case that's sometimes seen in RESTful APIs, upserting. That essentially means that we'd be creating a resource with put or patch. In some cases that's perfectly valid. We'll look into this as well. After this module, we'll have covered all the common HTTP methods for interacting with an API. So we'll end this with an overview of which method to use on which resource for what use case. Let's dive in immediately with put for full updates.
Working with Validation and Logging Hi there, and welcome to the Working with Validation and Logging module from the Building a RESTful API with ASP. NET Core course at Pluralsight. My name is Kevin, and I'll guide you through this module. When creating or updating resources, the inputted data often must be checked against a set of rules, for example, a title might have to be smaller than a specific number of characters. In this module, we'll learn what parts validation in a RESTful world consists of. From that, we'll then implement validation when creating and updating resources. When a validation error happens or something else goes wrong, an error, a fault, additional information we want to keep, we might want to log this fact. We'll cover how we can do that in ASP. NET Core. It includes a built into logger for this. We'll include logging to a file as well.
Implementing Paging, Filtering, and Searching Hi there, and welcome to the Implementing Paging, Filtering, and Searching Module from the Building a RESTful API with ASP. NET Core course at Pluralsight. I'm Kevin, and I'll guide you through this module. In this and in the next module, we'll implement common functionality for RESTful APIs. APIs typically have a need for paging on their collection resources to avoid performance implications, and those same collection resources sometimes have to be filtered or searched through. Even for these types of functionality for which the parameters are all passed through via the query string, it's important to keep RESTful principles in mind, especially when thinking about how we should return metadata. We'll notice this quite quickly as it comes into play when we cover pagination metadata. Let's dive into paging immediately.
Implementing Sorting and Data Shaping Hi there, and welcome to the Implementing Sorting and Data Shaping module from the Building a RESTful API with ASP. NET Core course at Pluralsight. I'm Kevin, and I'll guide you through this module. We ended the last module with filtering and searching, but a lot of APIs require additional functionality. A consuming application might want to choose how to order the resources in a list, not only by one field, but by multiple fields, both ascending and descending. And then there's the principle named data shaping, or shaping resources. This allows consumers to choose which fields of the resource should be in the representation. So let's continue where we left off in the previous module by looking into sorting.
Getting Started with HATEOAS Hi there, and welcome to the Getting Started with HATEOAS module from the Building a RESTful API with ASP. NET core course at Pluralsight. I'm Kevin and I'll guide you through this module. Only one subject this time: Hypermedia as the Engine of Application State. One of the sub-constraints of the uniform interface constraint. In this module, we'll cover exactly what it is, what it helps with, and how we can implement it in different scenarios. It's quite a big subject, so let's dive in immediately.
Advanced HATEOAS, Media Types, and Versioning Hi there, and welcome to the Advanced HATEOAS, Media Types and Versioning module of the Building a RESTful API with ASP. net Core Course at Pluralsight. I'm Kevin, and I'll guide you through this module. We ended the last one with a bit of an issue. Are the HATEOAS links part of each resource or representation? We'll look into that by looking into content negotiation again. That also means we'll dive a bit deeper into media types in this module, which quite naturally leads to versioning. Let's get started.
Working with Caching and Concurrency Hi there, and welcome to the Working with Caching and Concurrency module of the Building a RESTful API with ASP. NET Core course at Pluralsight. I'm Kevin, and I'll guide you through this module. We've got one more constraint to cover. Cacheability. Caching responses can dramatically improve performance, but caching is not easy. It's also one of the first things to look at when unexplainable bugs seem to happen. We'll tackle caching first. After that, we'll look into concurrency, i. e. , how can we ensure that when two people are working on the same resource, an update of the resource by the first person no longer overrides the changes the second person made in the meantime. But first, let's dive into caching.
Protecting, Testing, and Documenting Our API Hi there, and welcome to the Protecting, Testing, and Documenting Our API module from the Building a RESTful API with ASP. NET Core Course at Pluralsight. This is the last module, and I'm still Kevin, so I'll guide you through it. We'll start out by looking into protecting our API with rate limiting and throttling. That allows us to protect the API against too many requests. Too many requests might be detrimental for performance, so we do want to keep that in check. Then we'll cover testing. How can we write tests for API actions, and can this be integrated into a continuous integration scenario? We'll see what our options are. After we've protected and tested our API, we may want to expose it to consumers. Especially for public APIs, documentation that's different from the technical design you might not be allowed to share outside of company walls can come in handy. And lastly, we'll look into how we can support consumers testing our API. For example, how they can check if a resource exists, and how they can check what is allowed on a specific resource. As you notice from that description, that kind of adds to what HATEOAS already does. But let's start out with rate-limiting and throttling.