En 2026, PHP sigue siendo una opción muy válida para construir APIs REST. La clave está en elegir bien la herramienta según lo que necesitas construir, porque las diferencias entre frameworks son grandes y elegir mal al principio cuesta caro.
Tienes cuatro caminos principales:
- Laravel: el más completo. Incluye enrutamiento, autenticación con JWT o Sanctum, serialización con API Resources, validación con Form Requests y documentación con L5-Swagger. Si necesitas una API que crezca con el tiempo y quieres todo integrado, Laravel es la opción más madura.
- Slim Framework: un microframework que solo te da routing, middleware y soporte para PSR-7. Nada más. Tú eliges el ORM, el sistema de autenticación y lo demás. Perfecto cuando sabes exactamente qué necesitas y no quieres cargar con lo que no usas.
- API Platform: construido sobre Symfony, genera automáticamente endpoints REST y GraphQL a partir de tus entidades Doctrine. Documentación OpenAPI incluida sin hacer nada extra. Si tu API es básicamente CRUD con algo de lógica por encima, te ahorra semanas de trabajo.
- PHP puro: sin ningún framework. Válido para APIs muy pequeñas o cuando necesitas control total sobre cada detalle sin ningún overhead.
PSR-7 y PSR-15: el estándar de HTTP en PHP
Antes de entrar en los frameworks, conviene entender qué son PSR-7 y PSR-15, porque aparecen en casi todas las librerías modernas de PHP.
PSR-7 define interfaces estándar para representar mensajes HTTP: requests y responses. Las implementaciones más usadas son Nyholm/psr7, Guzzle PSR-7 y Laminas Diactoros. Si tu código depende de estas interfaces en lugar de una implementación concreta, puedes cambiar de librería sin tocar nada más.
PSR-15 define la interfaz para middleware HTTP:
MiddlewareInterface::process(
ServerRequestInterface $request,
RequestHandlerInterface $handler
): ResponseInterfaceSlim, Mezzio y otros microframeworks se construyen sobre estas interfaces. La ventaja práctica es que un middleware escrito para PSR-15 funciona en cualquier framework compatible, lo que facilita compartir código entre proyectos.
Slim Framework: ligero y sin opiniones
Slim es la opción cuando quieres un framework que no te imponga nada. Un endpoint básico se parece a esto:
$app = AppFactory::create();
$app->get('/usuarios/{id}', function (Request $req, Response $res, array $args) {
$data = ['id' => $args['id'], 'nombre' => 'Ana García'];
$res->getBody()->write(json_encode($data));
return $res->withHeader('Content-Type', 'application/json');
});
$app->run();Slim no incluye ORM, autenticación ni validación. Eso puede sonar a desventaja, pero es su punto fuerte: tú decides si usas Doctrine DBAL, Eloquent standalone o acceso directo a PDO. Para autenticación, puedes meter firebase/php-jwt directamente sin que el framework te ponga límites. El resultado es una API con exactamente las dependencias que necesitas y ninguna más.
Para APIs pequeñas con requisitos muy específicos, la combinación Slim + Doctrine DBAL + JWT funciona muy bien y mantiene el proyecto entendible sin tener que conocer la magia interna de un framework grande.
API Platform: CRUD automático desde tus entidades
API Platform funciona de forma distinta. En lugar de definir rutas a mano, anotas tus entidades Doctrine y el framework genera los endpoints por ti:
#[ApiResource]
#[ORMEntity]
class Producto
{
#[ORMId, ORMGeneratedValue, ORMColumn]
public int $id;
#[ORMColumn(length: 255)]
public string $nombre;
#[ORMColumn(type: 'decimal', precision: 10, scale: 2)]
public float $precio;
}Con esto tienes automáticamente GET /productos, GET /productos/{id}, POST /productos, PUT /productos/{id} y DELETE /productos/{id}, más la documentación OpenAPI en /api/docs.
Los filtros son igual de directos. Si quieres búsqueda por nombre:
#[ApiFilter(SearchFilter::class, properties: ['nombre' => 'partial'])]Eso añade automáticamente soporte para ?nombre=tablet en las peticiones GET. La serialización la controla el Serializer de Symfony mediante grupos, así que puedes exponer distintos campos según la operación sin escribir transformadores a mano.
Donde más se nota el ahorro es en proyectos con mucho CRUD estándar. Si tienes 20 entidades y necesitas CRUD completo para cada una, API Platform hace ese trabajo en horas en lugar de semanas.
Autenticación: JWT y Laravel Sanctum
Para APIs stateless, JWT es la opción habitual. En Laravel tienes dos librerías principales: php-open-source-saver/jwt-auth (el fork activo de tymon/jwt-auth) para tokens JWT completos, y Sanctum para tokens más simples orientados a SPAs y apps móviles.
Con JWT el flujo básico es:
// Login: generar el token
$token = Auth::attempt(['email' => $request->email, 'password' => $request->password]);
if (!$token) {
return response()->json(['error' => 'Credenciales incorrectas'], 401);
}
return response()->json(['token' => $token]);El cliente incluye el token en cada request con el header Authorization: Bearer {token}. No hay sesión ni cookie: el servidor valida el token en cada llamada y listo.
Sanctum es más sencillo de configurar y suficiente para muchos casos. Si tu API solo la consumen tu propia SPA o tu app móvil, Sanctum evita la complejidad extra de JWT.
Validación y serialización de respuestas
Laravel tiene dos herramientas muy útiles para esto: Form Requests y API Resources.
Un Form Request centraliza la validación:
class CreateProductoRequest extends FormRequest
{
public function rules(): array
{
return [
'nombre' => 'required|max:255',
'precio' => 'required|numeric|min:0',
'categoria_id' => 'required|exists:categorias,id',
];
}
}Si la validación falla, Laravel devuelve automáticamente un 422 con los errores. No tienes que escribir ese código tú.
Un API Resource controla qué campos expones y cómo los formateas:
class ProductoResource extends JsonResource
{
public function toArray($request): array
{
return [
'id' => $this->id,
'nombre' => $this->nombre,
'precio' => number_format($this->precio, 2),
];
}
}Así nunca expones campos internos por accidente ni dependes del formato que tenga el modelo en base de datos. Si el día de mañana cambias la estructura interna, la respuesta de la API no cambia.
Rate limiting
Sin rate limiting, cualquier endpoint público es un blanco fácil para abuso o scraping masivo. En Laravel lo más rápido es añadir el middleware throttle a las rutas:
Route::middleware('throttle:60,1')->group(function () {
Route::get('/productos', [ProductoController::class, 'index']);
});Eso limita a 60 peticiones por minuto por IP. Para límites por usuario autenticado, defines el rate limiter en AppServiceProvider:
RateLimiter::for('api', function (Request $request) {
return Limit::perMinute(100)->by($request->user()?->id ?: $request->ip());
});Las respuestas incluyen automáticamente los headers X-RateLimit-Limit y X-RateLimit-Remaining para que el cliente sepa cuántas peticiones le quedan. Cuando supera el límite recibe un 429.
Versionado y documentación OpenAPI
El versionado de APIs es uno de esos temas que parece menor al principio y luego resulta ser crítico. Si lanzas una API sin versionar y después necesitas cambiar un contrato, rompes todos los clientes existentes. La solución más simple es prefijo de ruta:
// v1
Route::prefix('api/v1')->group(function () {
Route::apiResource('productos', ProductoV1Controller::class);
});
// v2, cuando la necesites
Route::prefix('api/v2')->group(function () {
Route::apiResource('productos', ProductoV2Controller::class);
});Para la documentación, en Laravel puedes usar darkaonline/l5-swagger, que genera la especificación OpenAPI a partir de atributos PHP en los controladores:
#[OAGet(
path: '/api/v1/productos',
summary: 'Lista de productos',
tags: ['Productos'],
responses: [
new OAResponse(response: 200, description: 'OK')
]
)]
public function index(): JsonResponse
{
// ...
}La ventaja de generarlo desde el código es que la documentación no se desincroniza: si cambias el endpoint y actualizas el atributo, la documentación cambia con él. Con API Platform esto ya viene de serie, sin configurar nada.
¿Cuál elegir?
La respuesta depende del tamaño y los requisitos del proyecto. Para APIs pequeñas con requisitos muy concretos, Slim te da control total con muy poco overhead. Si tu API es principalmente CRUD sobre varias entidades y quieres documentación automática, API Platform es difícil de batir. Para proyectos que van a crecer o que necesitan autenticación, colas, notificaciones y más, Laravel te da todo integrado y bien mantenido.
Si quieres saber más sobre cómo estructurar tus endpoints para que sean consumibles por herramientas externas, lee APIs PHP que los modelos de IA pueden usar: estructura y contratos. Y si te preocupa la seguridad en APIs PHP: validación, rate limiting y más, ahí tienes un repaso completo de los puntos críticos.
Imagen: Pexels / RealToughCandy.com