In 2026 you open Claude or Copilot, type "build me a Laravel REST API with authentication" and five minutes later you have something running. So why write a book? Why would you read one?
Now look at that code and tell me whether you actually read it or just checked that it ran. You didn't write it and you didn't decide any of it. If it falls over in production tomorrow, the only thing you know how to do is reopen the same chat and ask for a fix, because you know nothing about that code that you didn't know before generating it.
The question that matters is what you put in it. If the answer is the prompt, your contribution is a request anyone can write, anywhere in the world, for a fifth of your salary. At that point the story about AI replacing us sooner or later no longer concerns you: you're already replaced. Your company just hasn't put it in writing yet.
The alternative is not giving up the model, it's refusing to take its output on faith. It generates, you decide whether that query survives real traffic, whether that validation covers the input nobody thought of, whether that authorization rule lets one user read another user's data. Those are questions the model won't ask on its own. You have to ask them, and you can only ask them if you know they exist.
Writing code is worth nothing anymore, because anyone can do it in five minutes. What's worth something is the thinking you put into it. If you put in none, the most expensive and slowest link in the production chain is you.
The book is there to put you back on the deciding side. I've been building with Laravel for years, and the APIs in it are built like the ones I ship to production, not like the ones people write to make examples.
An API is not a sum of endpoints
The model writes a single endpoint very well. But an API is a chain of decisions that condition each other, where none of them makes sense looked at alone. You can't ask for that coherence one piece at a time, because one piece at a time is exactly how you lose it.
That's why the book follows one API from start to finish. It's called BookShelf, it starts from a clean Laravel install and ends with a deploy on a VPS. The domain is deliberately boring, a catalog of books with authors and genres, because I don't want you spending time decoding the business while you're trying to understand how an API is put together. What you learn there moves to any other domain without changing a line of the reasoning.
Every line of code is explained and the source is on GitHub with a git tag at the end of each chapter, so you can download the project as it was at any point in the book. When a chapter makes a decision, the chapters after it carry that decision along, with everything that entails.
The things you need to be able to judge
It starts with how the API is designed, which is the part the model guesses worst: which resources you expose, what your status codes are actually telling the client, how to structure an error response that explains what went wrong instead of just failing. From there it moves to validation with Form Requests, authentication with Sanctum and authorization with Policies, which are three different problems even though too many projects mash them into the same controller.
Then come the things you only see under load or under attack. Eager loading and N+1, the point where most Laravel APIs fall over once the data gets real. Rate limiting, CORS and the vulnerabilities you need to know before opening your API to the world. And at the end, what tells you whether the work is actually done: tests with Pest, documentation generated with Scribe and a zero-downtime deploy with Envoy.
Twenty chapters, in this order, because it's the order in which the problems hit you. And you don't have to take my word on the level: the chapter on eager loading and N+1 is yours, whole and free, link at the bottom.
The chapter you'll want to read first
The last chapter is about Claude Code, and it's not what you'd expect from a book published now. I don't tell you AI changed my life. I show you how I use it on a real working day: what I ask it, what I re-read line by line before trusting it, when I throw away what it proposed without arguing about it. It sits at the end for a precise reason. After nineteen chapters you can spot at a glance a query that won't hold, a leaky validation, a badly written Policy, so the model becomes someone who works for you. Read that chapter first and you stay someone who works for the model.
Who it's for, and who it isn't
You know PHP and you want to build REST APIs that hold up in production. You don't have to know Laravel already: if you come from Symfony, WordPress or plain PHP, I explain every piece of the framework the moment it comes into play.
If instead you've been working with Laravel for years and you move through Policies, queues and Resources with your eyes closed, you can safely skip a good part of the book.
It's a different story if what you're looking for is a way to churn out APIs without having to understand them. That book exists, but I didn't write it.
Where to start
The book is on Amazon: antonio.popolizio.it/laravel-rest-apis
If you want to see how I write first, the chapter on eager loading and N+1 is free at antonio.popolizio.it/laravel-rest-apis/sample.pdf: you download it and that's it. No form, no leaving your email, no signing up for anything.
If you read the book, write me. Whether you liked it or not, I want to know.
In italiano lo trovi qui: antonio.popolizio.it/api-rest-laravel