Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 5 Siguiente »

Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad


Contenido


Resumen
  • Versión: v01r01
  • Fecha publicación:  
  • Entrada en vigor desde:
  • Deprecado

Cumplimiento normativo

Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.

La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.

En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.

Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es

Obsolescencia

Los nuevos desarrollos enmarcados dentro de la STIC hacen uso de algunas soluciones tecnológicas más actuales. El documento actual, pretende servirle de ayuda para aquellos desarrollos más antiguos, puede ser que su solución provea de una pila tecnológica más actual que la que aquí está descrita. En tal caso se propondrán los asuntos al área de arquitectura para determinar el enfoque.

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.

Versiónv01r02Fecha publicación

 

Fecha entrada en vigor


Alcance
  • Actualización del documento con el punto 2. Comunicación entre cliente servidor
Versiónv01r01Fecha publicación

 

Fecha entrada en vigor

 

Alcance
  • Versión inicial sobre normativa sobre compatibilidad de aplicaciones web con navegadores de escritorio

1. Normativa de Clientes Web

Para una continua actualización y uso de los aplicativos en tecnologías y navegadores modernos, se proponen unas técnicas para eliminar o minimizar la incompatibilidad de los aplicativos entre diferentes navegadores, tecnologías y estilos.

Se recomienda la técnica de "Graceful degradation" para la construcción de los aplicativos, esto quiere decir que se proveerá con la máxima experiencia de usuario en los navegadores más modernos, y esta ira degradándose de manera controlada a un nivel menor en navegadores antiguos, siempre ofreciendo la misma funcionalidad básica.

Hay que hacer foco en tres áreas principales a la hora de la compatibilidad, JavaScript, CSS, y HTML

  • JavaScript:
    Uso de la especificación ECMAScript 5  (En este enlace podéis comprobar los navegadores compatibles: http://kangax.github.io/compat-table/es5/)
    Para evitar incompatibilidades y facilitar el desarrollo se recomienda el uso de las siguientes librerías:
    • jQuery: Ofrece muchas funcionalidades, sobre todo relacionadas con el tratamiento del DOM, y la realización de peticiones ajax.
    • modernizr: Librería que permite la detección y la carga condicional de javascripts y css, lo que permite fácilmente ofrecer recursos específicos para navegadores concretos.
  • CSS: Para evitar problemas de estilos entre navegadores se debe de hacer uso de css que normalicen los estilos entre los navegadores, por ejemplo normalize.css    
  • HTML: Se usara HTML4

Otras detalles a la hora de desarrollar:

  • Seguir el estándar  w3c
  • Evitar el uso de "hacks", sobre todo hacks de CSS
  • No extender el DOM
  • Hacer test automáticos de la interfaz

2. Comunicación entre cliente servidor

Para la comunicación cliente servidor, siempre y cuando no haya ningún inconveniente de aplicación de la tecnológica por obsolescencia en los navegadores, será de obligado cumplimiento hacer uso de fetch para articularla.

Dicho modelo se basa en la siguiente especificación viva https://fetch.spec.whatwg.org/#http-network-fetch.

Tenga en cuenta aspectos concretos que pueden resultarle nuevos por el modo en que los navegadores modernos manejan la comunicación, cómo:

  • Capitalización en las cabeceras
    • Preste atención al modo en que fetch ha de tratar las cabeceras
      • Todas las propiedades de las cabeceras a incluir han de ser byte-case-insensitive, aunque se recomienda el uso de: PascalCase (capitalizando todas las palabras) + kebab-case (separando las palabras con guiones) → p.e. "Content-Type"
  • Obteniendo información extra sobre verbos autorizados y CORS haciendo uso de OPTIONS
    • El metodo HTTP OPTIONS se usa para definir las opciones de comunicación para un determinado recurso, es decir, el cliente puede mandar una petición HTTP OPTIONS para averiguar que métodos y otras opciones son admitidas por dicho recurso. Estas peticiones solo devuelven datos, es decir, el servidor no debe cambiar su estado.
    • Estas solicitudes se utilizan en el navegador como una "solicitud de verificación previa", un mecanismo en CORS para comprobar si el recurso destino aceptará la petición final o no. Dicho mecanismo consiste en enviar el metodo HTTP OPTIONS con Access-Control-Allow-Origin, Access-Control-Request-Method y Access-Control-Request-Headers en la cabecera para notificar al servidor sobre el tipo de petición que se quiere enviar. La respuesta deberá ser 200 (OK) para que que la petición real sea enviada.
  • CORS

    • Definición: El uso compartido de recursos de origen cruzado (CORS) es un mecanismo que utiliza encabezados HTTP adicionales para indicar a los navegadores que den a una aplicación web que se ejecuta en un origen acceso a recursos seleccionados de un origen diferente.

  • Sin etiquetas