Herramientas de usuario
ada:howto:sicoferp:factory:new-migracion-sicoferp:manifiestoback
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
|
ada:howto:sicoferp:factory:new-migracion-sicoferp:manifiestoback [2024/12/10 12:27] 192.168.175.142 |
ada:howto:sicoferp:factory:new-migracion-sicoferp:manifiestoback [2024/12/10 12:58] (actual) 192.168.175.142 |
||
|---|---|---|---|
| Línea 13: | Línea 13: | ||
| Los nombres de las clases(entidades,dto's,components,service) deben ser claros y consistentes al proceso que se realiza, por ejemplo: si se mapea una tabla deberá tener la estructura CamelCase esto para dar orden y legibilidad asi: | Los nombres de las clases(entidades,dto's,components,service) deben ser claros y consistentes al proceso que se realiza, por ejemplo: si se mapea una tabla deberá tener la estructura CamelCase esto para dar orden y legibilidad asi: | ||
| - | ^Nombre de la tabla en BD^Nombramiento de la clase^ | + | ^Nombre de la tabla en BD^Nombramiento de la Entidad^Nombramiento del Component^Nombramiento del service^Nombramiento del Repository^ |
| - | |DET_DISPONIBILIDAD| DetalleDisponiobilidad | | + | |DET_DISPONIBILIDAD| DetalleDisponibilidad | DetalleDisponibilidadComponent|DetalleDisponibilidadServicce|DetalleDisponibilidadRepository| |
| 3. Modularidad y Reusabilidad | 3. Modularidad y Reusabilidad | ||
| Línea 20: | Línea 20: | ||
| El código debe ser estructurado en módulos pequeños, reutilizables y fáciles de probar. Las funcionalidades comunes deben ser encapsuladas en servicios o bibliotecas reutilizables. | El código debe ser estructurado en módulos pequeños, reutilizables y fáciles de probar. Las funcionalidades comunes deben ser encapsuladas en servicios o bibliotecas reutilizables. | ||
| + | 4.Nombramiento de los proyectos y paquetes. | ||
| + | |||
| + | Al momento de crear los servicios basados en el arquetipo, él nombramiento del GroupId y Package debe ser en minúscula y separado por puntos asi: com.ada.module.presupuesto.ordendepago. | ||
| + | |||
| + | Para el ArtefactId debe tener estructura CamelCase así: OrdenDePago. | ||
| + | |||
| + | Para la Versión debe tener la siguiente estructura x.x.x donde si es un proyecto nuevo deberá quedar así:0.0.1-SNAPSHOT. | ||
| + | |||
| **'' Estructura de la API:''** | **'' Estructura de la API:''** | ||
| Línea 67: | Línea 75: | ||
| Las APIs deben devolver errores de manera estandarizada. La respuesta debe incluir un código de estado HTTP adecuado y un cuerpo de respuesta con un mensaje descriptivo del error: | Las APIs deben devolver errores de manera estandarizada. La respuesta debe incluir un código de estado HTTP adecuado y un cuerpo de respuesta con un mensaje descriptivo del error: | ||
| - | || | + | |
| - | |{ | + | { |
| "status": "INTERNAL_SERVER_ERROR", | "status": "INTERNAL_SERVER_ERROR", | ||
| "statusCode": 404, | "statusCode": 404, | ||
| Línea 78: | Línea 86: | ||
| "Revise el estado de la conexión." | "Revise el estado de la conexión." | ||
| ], | ], | ||
| - | "logProcess": ""}| | + | "logProcess": ""} |
| **''Seguridad:''** | **''Seguridad:''** | ||
| Línea 87: | Línea 94: | ||
| Las APIs deben requerir autenticación a través de métodos seguros, como JWT (JSON Web Tokens) o OAuth 2.0. No deben almacenarse credenciales en texto claro. | Las APIs deben requerir autenticación a través de métodos seguros, como JWT (JSON Web Tokens) o OAuth 2.0. No deben almacenarse credenciales en texto claro. | ||
| - | 2. CORS (Cross-Origin Resource Sharing) | + | 2. Protección contra Inyecciones |
| - | + | ||
| - | Las políticas de CORS deben ser configuradas para permitir el acceso seguro desde los orígenes que se necesiten, y se deben evitar configuraciones demasiado abiertas. | + | |
| - | + | ||
| - | 3. Protección contra Inyecciones | + | |
| Se deben aplicar medidas de seguridad como la validación de entrada, uso de consultas parametrizadas y escaneo de vulnerabilidades de inyección SQL, XSS, CSRF, entre otros. | Se deben aplicar medidas de seguridad como la validación de entrada, uso de consultas parametrizadas y escaneo de vulnerabilidades de inyección SQL, XSS, CSRF, entre otros. | ||
| Línea 110: | Línea 113: | ||
| Es fundamental que las APIs tengan una buena cobertura de pruebas unitarias, de integración y de aceptación. Las pruebas deben ser automatizadas siempre que sea posible. | Es fundamental que las APIs tengan una buena cobertura de pruebas unitarias, de integración y de aceptación. Las pruebas deben ser automatizadas siempre que sea posible. | ||
| - | |||
| - | 2. Pruebas de Seguridad | ||
| - | |||
| - | Las APIs deben ser sometidas a pruebas de seguridad regulares, como pruebas de penetración y revisiones de vulnerabilidades. | ||
| **''Manejo de Logs:''** | **''Manejo de Logs:''** | ||
ada/howto/sicoferp/factory/new-migracion-sicoferp/manifiestoback.1733833663.txt.gz · Última modificación: 2024/12/10 12:27 por 192.168.175.142
Herramientas de la página
