Incremental APIs

The "oh no she didn't" approach to building an API in Laravel is to simply return the result of an Eloquent query from your controller. Sure, Laravel is smart enough to cast this to JSON, but are you sure that's what you want to do? Let's talk about that.

Returning the proper HTTP status codes (and potentially application-specific codes) is paramount to building a successful API.

We need to solve that issue of linking our API output to the structure of our database tables. One remedy might be to leverage transformations. We'll discuss that very thing in this lesson.

The problem with HTTP status codes is that they can be difficult to remember. Rather than relying on "magic numbers" in our controllers, what if we instead abstract all that away to readable methods in a parent class?

What happens when we want to limit access to our API? Well, clearly, we'll need some form of authentication. Let's start with the simplest solution: HTTP basic authentication (with SSL).

As we prepare for a follow-up lesson on nested resources, let's return to our database seeders, and focus on refactoring and debugging.

Now that we're successfully presenting lessons to the consumers of our API, let's switch over to tags. Luckily, because most of the infrastructure is in place, allowing for nested resources will be fairly painless!

Readability is the key to a successful test suite. We often throw around this word for production code, and then completely ignore the concept when it comes to testing. Don't do that! Let me help.

We made a lot of progress in the previous episode on testing our API, but there's still room for improvement. These tests need to be as simple as possible to write. How can we allow for that?

We've ignored that pesky Lesson::all() long enough! Sure, it's fine when we have fifty records, but what about when that number becomes fifty thousand? Do you really want to fetch all those for each request? Of course you don't. Let's figure out how to paginate our API results.