Pantallas y datos
OpenAPI describe las operaciones y JSON Schema los datos. Las vistas portables combinan formularios, tablas, detalles y comandos en páginas, con diseños opcionales de JSON Forms, sin exigir un framework concreto.
Una especificación para módulos de administración portables
Muchos servicios.
Un lenguaje
común.
Estamos desarrollando una forma común de conectar servicios y microservicios a una sola interfaz de administración, con reglas compartidas de acceso, separación de datos y auditoría.
Descubre la ideaEspecificación en desarrollo · Borrador 0.1.0
FIG. 01UN CONTRATO COMÚN
QUÉ ESTAMOS CREANDO
Un solo espacio para gestionar los servicios de tu producto
OpenAdminSpec es un borrador de especificación para conectar servicios independientes a una interfaz de administración compartida. Cada servicio describe qué se puede gestionar y cómo; una plataforma usa esa descripción para mostrar pantallas, comprobar el acceso y llamar a su API.
Al crecer un producto, la facturación, las cuentas y el contenido suelen acabar en herramientas separadas. Los equipos rehacen formularios, tablas e integraciones para cada servicio. Un contrato común busca hacer reutilizable ese trabajo, manteniendo la API y las reglas de negocio de cada servicio.
CÓMO ENCAJA TODO
Describir, conectar, gestionar
-
Describir el servicio
El equipo publica un módulo que describe las acciones de su API, las pantallas, los datos y los requisitos de acceso. El módulo contiene el contrato de administración; el servicio implementa las operaciones.
-
Aprobar una conexión
Un operador revisa el módulo y conecta una instancia concreta del servicio a la plataforma. Aprueba su dirección, credenciales, versión y permisos, además de los proyectos asociados cuando sean necesarios.
-
Trabajar mediante su API
Una plataforma compatible construye la interfaz descrita. Al ejecutar una acción, comprueba los permisos, aporta el contexto aprobado y llama al servicio, que aplica sus propias reglas.
EL CONTRATO
Qué reúne la especificación
Autenticación y permisos
Autenticarse ante una API y tener permiso para actuar son cuestiones distintas del inicio de sesión en el panel. Plataforma y servicio deben comprobar el acceso; las credenciales quedan fuera del módulo.
Tenants y conexiones
Varias conexiones independientes pueden reutilizar un módulo. Los tenants son clientes o proyectos con datos y permisos propios, y son opcionales. La plataforma selecciona su contexto; los servicios deben garantizar la separación de datos.
Acciones, tareas y archivos
Describe acciones inmediatas, tareas en segundo plano con progreso y resultados, y transferencias controladas de archivos. Todas mantienen los permisos y el contexto del servicio o proyecto seleccionado.
Versiones y aprobación
La validación comprueba los documentos. La plataforma debe ofrecer las capacidades exigidas antes de aprobar una conexión o actualización. Las versiones aprobadas no cambian; elegir otra para una conexión requiere aprobación.
Un formato común de auditoría
Registra quién inició una acción, a qué conexión o proyecto pertenecía y qué resultado se confirmó. Los campos comunes permiten seguir la solicitud y distinguir operaciones completadas, fallidas o con resultado incierto.
POR EJEMPLO
Un producto, varios servicios
Imagina un producto de suscripción con servicios de facturación, cuentas y contenido. Soporte podría buscar una cuenta, finanzas revisar sus facturas y un editor actualizar el contenido del cliente desde un mismo espacio. Cada acción mantendría su servicio, contexto y comprobaciones de permisos.
Los equipos de servicios podrían mantener sus módulos mientras el equipo de plataforma desarrolla herramientas comunes. Los cambios pasarían por una revisión de versión antes de afectar a conexiones activas. Esa es la dirección del borrador 0.1.0; las implementaciones se desarrollan por separado.
EN DESARROLLO
Un lenguaje común está tomando forma
La especificación es un borrador en evolución. El sitio completo estará disponible próximamente.