Often, pitfalls and traps are a good thing! They teach us about what to avoid the next time around. This is how best practices emerge. With that in mind, in this series, let's take an incremental approach to understanding API development with Laravel.
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!
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.