Instead of building yet another "Hello World" API, let’s use a real production API as our guide: the Webplo License API. It’s simple enough to grasp quickly, but real enough to show the patterns that matter.
The API does one thing, and it does it well: it manages website licenses.
Every Webplo site has its own license, issued automatically the moment the site is provisioned. From then on, the Webplo engines interact with this API to create, retrieve, and revoke licenses as needed. This isn’t an API designed for public consumption; it’s an internal microservice, one of the many components that power Webplo behind the scenes.
Behind the scenes, this API integrates directly with the Statamic License API, since every Webplo site runs on top of Statamic CMS. The integration is structured using a Manager, Facade, Driver pattern, allowing us to keep the core logic clean while supporting multiple drivers and future extensions.
The API also handles multilingual responses, rate limiting, asynchronous logging, and payload compression, not because it’s flashy, but because it needs to be reliable.
This is a production API that's actually serving real traffic. We're going to understand how it works and what makes it work well.
Starting From Zero
If you want to follow along from scratch, let’s spin up a new Laravel project:
composer create-project laravel/laravel api-license
cd api-license
php artisan key:generate
That’s it. Laravel did most of the heavy lifting. When I started developing in PHP 12 years ago, setting up a framework meant manually wiring configuration files, tweaking bootstrap scripts, and stitching everything together before you could even write real code. Laravel simply says, “We’ve already thought about this. Here are sensible defaults.”
Now, one thing I want you to understand right from the start: you're not required to use Laravel's defaults. You can customize everything. But here's what I've learned: when you find yourself fighting the framework, that's usually a signal that you're making decisions the framework is trying to save you from.
The Structure That Makes Sense
Laravel 12 has evolved to a very clean structure. Here’s what each folder actually does:
app/Http/Controllers/ Your API endpoint logic
app/Http/Requests/ Input validation rules
app/Http/Resources/ Response formatting
app/Http/Middleware/ Request/response interception
app/Http/Mappers/ DTO transformations
app/Http/DataObjects/ DTO definitions
app/Http/Integrations/ External API integrations
app/Http/Responses/ Unified Response Wrappers
app/Models/ Database models (like Bearer token)
app/Services/ Business logic with manager pattern
routes/api.php Where you define endpoints
tests/Feature/ Testing full request flows
database/migrations/ Database versioning
Each folder has a purpose. Controllers handle HTTP. Models handle the database. Facades provide clean interfaces. Tests verify everything works. When a new developer joins your team and looks at this structure, they think, "oh, I've seen this before." That consistency matters.