API REST SIAP — Prácticas en Grupo SIAP

El problema

Grupo SIAP necesitaba una API REST que integrara su sistema de gestión empresarial con aplicaciones web, móviles y de escritorio. Hasta entonces, las integraciones se hacían caso por caso, sin un estándar común. Cada nuevo cliente implicaba adaptar la comunicación desde cero.

Yo llegué como estudiante de prácticas del ASIR. Era mi primera experiencia con código en producción real — no en un entorno académico, no en un proyecto personal. Cada endpoint que escribiera iba a ser consumido por otros desarrolladores y, eventualmente, por usuarios reales.

La decisión — PHP sin framework con JWT

La empresa usaba PHP nativo con una estructura propia. No podía llegar e imponer Laravel. Así que trabajé dentro de su ecosistema, organizando el código con una arquitectura limpia usando solo PHP: separación de rutas, controladores, modelos, y middleware de autenticación.

Para la autenticación, elegí JWT en lugar de sesiones con cookies. Las aplicaciones cliente podían ser web, móvil, o de escritorio, y JWT permitía que todas se autenticaran con el mismo mecanismo stateless.

Implementación

Endpoints desarrollados

Endpoint	Método	Función
/api/auth/login	POST	Autenticación, devuelve token JWT
/api/clientes	GET/POST	Listar / crear clientes
/api/clientes/{id}	GET/PUT/DELETE	CRUD de un cliente
/api/productos	GET/POST	Catálogo de productos
/api/pedidos	GET/POST	Pedidos con líneas de detalle
/api/facturas	GET	Generar factura en PDF

Decisiones técnicas

• PHP sin framework — me obligó a entender cómo funcionan los frameworks por debajo: routing, middleware, inyección de dependencias. Fue frustrante al principio, pero hoy sé exactamente qué hace Laravel cuando llamo a Route::post().
• JWT para sesiones stateless — cualquier cliente (web, móvil, escritorio) se autentica con el mismo token, sin depender de cookies de sesión.
• Validación doble — los datos se validan en el backend siempre, aunque el frontend ya lo haya hecho. Nunca confiar en el cliente.
• Códigos HTTP correctos — 201 para creación, 422 para validación, 401 para no autenticado. Cada endpoint responde con el código que toca, no siempre 200.

Lo que aprendí sobre producción real

Tres cosas que no se enseñan en clase:

1. El código en producción no es como los ejercicios del ciclo. En clase te piden que funcione. En producción te piden que funcione, que sea seguro, que gestione errores, que tenga logs, que no se caiga con 100 peticiones simultáneas, y que cuando algo falle, sepas exactamente qué pasó.

2. Documentar la API para otros desarrolladores. Escribir endpoints que otros puedan consumir sin llamarme significaba: respuestas JSON consistentes, mensajes de error descriptivos, y documentación clara de cada endpoint.

3. Git en equipo. No es lo mismo hacer commit de tu proyecto personal que trabajar con un repositorio donde otros hacen push, hay code review, y los merge conflicts son reales y duelen.

Métricas

Métrica	Valor
Duración	6 meses (agosto 2024 - junio 2025)
Endpoints	6 REST + autenticación JWT
Backend	PHP 8, MySQL
Autenticación	JWT stateless
Formato	JSON estructurado
Estado	En producción interna de Grupo SIAP

Qué cambiaría

Pruebas automatizadas desde el principio. En producción, cambiar un endpoint sin tests es jugar a la ruleta. Si volviera a empezar, escribiría los tests antes que los endpoints.

Documentación con OpenAPI/Swagger. Los endpoints los documenté en texto plano. Para una API que otros desarrolladores consumen, una especificación OpenAPI automatiza la generación de documentación y permite probar endpoints desde el navegador.

Lo que no cambiaría: PHP sin framework como primera experiencia. Fue la decisión correcta para aprender. Ahora que sé lo que pasa por debajo, usar un framework con confianza, no por inercia.

Este proyecto me confirmó que mi perfil no es solo sysadmin — también puedo desarrollar backend y entender las necesidades de quien consume una API.