Laravel API Master Class

We'll start our API from scratch with a basic Laravel project and build some simple routes that return JSON-formatted data. We'll also write a trait that we can use in our API controllers to simplify returning JSON structures.

The browser isn't a sufficient tool for working with web APIs. Instead, we need an HTTP debugger. There are many available, but we'll use Postman in this series. The right tool makes all the difference in the world.

Every application has a user interface--even web APIs! Except that our UI is the URL because that how users interact with our application. So, it's important to think about our URLs and design them to be logically usable.

Versioning is one of the most important parts of designing an API. It protects you from making breaking changes for your clients, and it helps to structure your project in a logical manner. Let's look at one of the ways you can implement versioning for your API.

Unlike typical web applications, APIs rely on tokens to determine if clients are authenticated. In this episode, you'll learn how to generate Sanctum tokens for clients and protect routes with the Sanctum middleware.

It is important to learn how to revoke client tokens to ensure the security of your API. I'll show you how to do that, as well as set an expiration time for your tokens.

The JSON response we send to clients are probably the most important things about our API--it's what clients are coming to our API for. It's not good enough (or safe) to just dump an Eloquent model to the response. So in this episode, you'll learn how to transform Eloquent models into well-structured JSON.

Different routes typically need to return different JSON structures--even if those routes work with the same resource. You can create as many Resource classes as you need to fit every situation, or you can use the tools the JsonResource class provides to conditionally omit and include data.

Some data, such as relationship data, doesn't need to be loaded and sent with every response. Instead, we want to give the client the option to include that data. In this episode, we'll use an include query parameter to allow clients to opt-in to loading relationship data.

Clients need to be able to filter the data that we provide. We can approach filters in a variety of ways, but in this episode, we'll map query string parameters directly to methods on a filter class.

Filtering ticket data based on the author ID is a little more complex than the basic filters we implemented in the previous episode. To be consistent with our payload, we'll access the author ID filter with a relationships query string parameter, and we'll apply the same methodology to our basic attributes, too.

An API is a glorified data access layer. So, it's not enough to just provide the ability to fetch and filter data; clients need to be able to sort on any attribute.

APIs need to provide much more than just fetching data; clients need to be able to create resources.

Deleting resources is probably the most straight-forward thing you will implement in your API.

There are two types of requests used to update a resource: PATCH and PUT, and they both do completely different things.

Updating resources with PATCH requests is a little more involved than with PUT requests--primarily because we have to update only the data that was provided in the request.

User authorization is so much more than determining if a user can do something. It also involves determining if a user can do something for a specific resource.

Sanctum's token abilities allow us to essentially assign roles or permissions to users without building a system ourselves or using an external package.

We can use token abilities for anything, including controlling which attributes a user can or cannot change.

We've covered filtering, handling requests, and permissions. Now we just need to apply all of those concepts to implement the AuthorTicketsController.

We've implemented ticket management, and now we need to implement the ability to manage users (with the appropriate permissions). Let's get to it.

I messed up. We all do it. We write some code, come back later, and think it's the worst code we've ever written. We need to apply the Principle of Least Privilege to our validation rules. So let's do it!

We handle some errors, but we need to handle any error that may occur within our application. We also need to return a consistent JSON structure for all of our errors, and we can easily accomplish this with the global exception handler.

Documentation is probably the most boring part of any project, but we need to do it. Our API is meant to be used! So, instead of writing the documentation ourselves, let's automate as much as possible by using Scribe.