Contratos de escritorio, LAN y pedidos móviles
Capacidades del restaurante, permisos, idempotencia y límites de los adaptadores locales.
Alcance de esta referencia#
Los contratos descritos corresponden a los adaptadores locales de Restaurante Pro revisados el 14 de octubre de 2026. Son una referencia para mantenimiento e integración autorizada; esta página no los presenta como una API pública de Internet con garantía independiente de compatibilidad.
El renderer de escritorio usa capacidades explícitas del preload y canales IPC. La terminal utiliza la API del host con autenticación y permisos. Los DTO compartidos definen entradas y snapshots; los adaptadores validan estructura y los casos de uso aplican las reglas de negocio.
| Capacidad | Ejemplo de contrato | Permiso |
|---|---|---|
| Consultar salón | GET /api/restaurant/workspace | restaurant.floor.read |
| Abrir mesa | POST /api/restaurant/sessions/dine-in | restaurant.orders.manage |
| Abrir para llevar | POST /api/restaurant/sessions/takeaway | restaurant.orders.manage |
| Enviar ronda | restaurant:order:send / POST /api/restaurant/orders | restaurant.orders.manage |
| Cambiar estado de cocina | POST /api/restaurant/kitchen/status | restaurant.kitchen.manage |
| Dividir o cobrar | POST /api/restaurant/bills/split y /bills/settle | restaurant.checkout.manage |
| Configurar | Rutas de áreas, mesas, estaciones, impresoras y opciones. | restaurant.configure |
Idempotencia y concurrencia#
Una ronda incluye sessionId, idempotencyKey y líneas con producto y cantidad. El resultado identifica la orden, la ronda, sus tickets y si reutilizó una ejecución previa. Conserva la misma llave al resolver un reintento incierto; generar una nueva puede representar otra intención de negocio.
La apertura móvil de mesa o pedido para llevar exige llave de idempotencia. Las transiciones de cocina pueden incluir expectedVersion para detectar un estado cambiado por otro operador. Las opciones del producto se envían por identificadores y el host resuelve los valores autorizados.
Sesión móvil#
La web se entrega bajo /mobile/orders/. La autenticación tiene rutas separadas bajo /api/mobile/auth/ y mantiene una cookie HttpOnly; SameSite=Strict. Las mutaciones validan el origen.
La cookie móvil solo habilita salud, consulta del workspace, detalle de sesión, apertura de mesa, apertura para llevar y envío de órdenes. No habilita cobro, configuración general ni acceso nativo. La web móvil no recibe SQLite, Node, Electron ni el token general de la LAN.
Respuestas y diagnóstico#
La API devuelve éxitos con ok y data. Los errores incluyen ok: false, mensaje, código y requestId; también se entrega X-Request-Id. Los errores internos se presentan de forma genérica. Usa el identificador para correlacionar el incidente sin registrar credenciales o cuerpos sensibles.