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/09 21:16] 192.168.175.142 |
ada:howto:sicoferp:factory:new-migracion-sicoferp:manifiestoback [2024/12/10 12:58] (actual) 192.168.175.142 |
||
|---|---|---|---|
| Línea 3: | Línea 3: | ||
| **''Principios Generales:''** | **''Principios Generales:''** | ||
| + | |||
| 1.Simplicidad y Claridad | 1.Simplicidad y Claridad | ||
| Línea 9: | Línea 10: | ||
| 2.Consistencia | 2.Consistencia | ||
| - | El código debe seguir convenciones y patrones consistentes para que sea más fácil de mantener y comprender por otros desarrolladores. Las herramientas como linters y formateadores automáticos son recomendables para mantener la consistencia. | + | El código debe seguir convenciones y patrones consistentes para que sea más fácil de mantener y comprender por otros desarrolladores. Las herramientas como linters(Cada ide debe tener el sonarLint activo con las reglas globales del sonar qube)y formateadores automáticos son recomendables para mantener la consistencia. Además se debe respetar la estructura MVC donde las peticiones entran al controlador ,van al service y de ahí al component(allí se realiza toda la lógica de negocio). |
| + | |||
| + | 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 Entidad^Nombramiento del Component^Nombramiento del service^Nombramiento del Repository^ | ||
| + | |DET_DISPONIBILIDAD| DetalleDisponibilidad | DetalleDisponibilidadComponent|DetalleDisponibilidadServicce|DetalleDisponibilidadRepository| | ||
| 3. Modularidad y Reusabilidad | 3. Modularidad y Reusabilidad | ||
| Línea 15: | 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 63: | Línea 76: | ||
| 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", |
| - | + | "statusCode": 404, | |
| - | ---- | + | |
| - | + | ||
| - | ejemplo de un error: | + | |
| - | + | ||
| - | || | + | |
| - | { | + | |
| - | "status": "INTERNAL_SERVER_ERROR", | + | |
| - | "statusCode": 404, | + | |
| "message": "Se han generado errores al intentar conectarse al cliente.", | "message": "Se han generado errores al intentar conectarse al cliente.", | ||
| "errors": [ | "errors": [ | ||
| Línea 81: | Línea 86: | ||
| "Revise el estado de la conexión." | "Revise el estado de la conexión." | ||
| ], | ], | ||
| - | "logProcess": ""}|| | + | "logProcess": ""} |
| - | + | ||
| - | + | ||
| - | ---- | + | |
| **''Seguridad:''** | **''Seguridad:''** | ||
| Línea 92: | 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 115: | 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.1733778978.txt.gz · Última modificación: 2024/12/09 21:16 por 192.168.175.142
Herramientas de la página
