API REST¶
Referencia de los endpoints del backend. Todo cuelga del context-path /autocompras/v1. La terminal consume las rutas de ticket/pago; el Cockpit consume /monitoring/* (documentado aparte en Cockpit).
No hay STOMP
El backend actual no expone WebSocket/STOMP: no hay @MessageMapping ni broker. La terminal habla REST. Si buscás el porqué, está en Comunicación POS ↔ Backend.
Convenciones¶
- Base:
/autocompras/v1(más la ruta de cada controller). - Healthchecks: cada módulo expone un
GET /*/dummy(/tickets/dummy,/articulos/dummy,/pagos/dummy,/promociones/dummy,/vales/dummy), todospermitAll. - Envoltura: muchas respuestas usan
ResponseMessage(del kernelshared). - Headers de terminal (los inyecta el
HttpClientedel POS):X-Cod-Terminal,X-Terminal-Uuid,X-Device-Health.
Tickets (orquestador)¶
TicketRestController y compañía. Es la API que mueve el carrito.
| Método | Ruta | Qué hace |
|---|---|---|
GET |
/tickets/dummy |
Healthcheck. |
POST |
/openTicket |
Crea un ticket (OPEN). |
POST |
/agregarArticulo |
Agrega un ítem (resuelve EAN en catalogo, recalcula promos). |
POST |
/removeItem |
Quita un ítem. |
POST |
/changeStatus |
Cambia el estado del ticket. |
POST |
/validateTicket |
Valida el ticket. |
POST |
/closeTicket |
Cierra el ticket (CLOSE). |
POST |
/payTicket |
Dispara el flujo de pago (intent/ejecución). Ver Pagos. |
El cliente: TicketService en la terminal
En TiprePOS cada una de estas mutaciones tiene su método en TicketService (openTicket, agregarArticulo, removeItem, closeTicket, changeStatus, validateTicket), despachado por el BackendClientBloc vía el evento SendMessage.
Catálogo¶
ArticuloRestController.
| Método | Ruta | Qué hace |
|---|---|---|
GET |
/articulos/dummy |
Healthcheck. |
GET |
/searchBy?ean=&sucursal=&page=&limit= |
Busca artículos (también por id, codigoInterno, descripcion). Paginado, máx. 200 ítems. |
POST |
/catalogo/cache/refresh |
Refresca la cache Caffeine. Rol admin si la seguridad está activa. |
Pagos¶
PagoRestController. Stateless; sale a los gateways.
| Método | Ruta | Qué hace |
|---|---|---|
GET |
/pagos/dummy |
Healthcheck. |
POST |
/payment-intent |
Crea la intención de pago. Async (Mono<ResponseEntity>). |
POST |
/pay |
Procesa el pago. |
GET |
/check-status/{paymentId} |
Verifica el estado de un pago. |
Promos¶
PromoController.
| Método | Ruta | Qué hace |
|---|---|---|
GET |
/promociones/dummy |
Healthcheck. |
GET |
/promociones |
Lista promociones. |
POST |
/promociones/update |
Actualiza promociones. Rol admin. |
POST |
/cache/refresh |
Refresca la cache de promos. Rol admin. |
Envases / Vales¶
ValeController (@RequestMapping("/vales")) y EnvaseController.
| Método | Ruta | Qué hace |
|---|---|---|
GET |
/vales/dummy |
Healthcheck. |
GET |
/vales?codVale= |
Obtiene un vale por su código (encriptado). |
POST |
/vales |
Crea un vale. |
PUT |
/vales/{id} |
Actualiza un vale. |
Salud / Actuator¶
| Método | Ruta | Qué hace |
|---|---|---|
GET |
/actuator/health |
Health check (Actuator). permitAll. |
GET |
/actuator/info |
Info de build. permitAll. |
GET |
/status |
Estado de servicios que la terminal consulta por polling (60 s / 15 s). |
Rutas implícitas
Algunas rutas (pay, check-status, alta/edición de vales) se infieren del patrón de cada controller y pueden variar en la firma exacta. Ante la duda, el código del controller es la fuente de verdad, no esta tabla: las rutas viven en src/main/java/com/tipre/autocompras/*/controller/.