AMD
Son las siglas en inglés de Asynchronous Module Definition, o Definición Asíncrona de Modulos (DAM en español, pero nadie lo usa).
Se trata de una especificación que define una manera estándar de cargar definiciones de módulos y sus dependencias en código JavaScript de lado cliente. Su representante más conocido es Require.js, aunque existen otros. Es indispensable en aplicaciones web grandes y en especial en desarrollos de tipo Single Page Application (SPA).
Algunos recursos interesantes:
Bundling
Es un proceso que consiste en combinar varios archivos de código JavaScript (.js) o CSS (.css) en uno solo. De este modo se reduce el número de peticiones que una página debe realizar al servidor, lo que ahorra tiempo y ancho de banda.
Generalmente se combina con un proceso de minimización (se le suele llamar también "minificación" aunque la palabra realmente no existe en español). Este proceso reduce él tamaño de cada archivo individual eliminando espacios innecesarios, reduciendo el nombre de las variables, etc... para lograr archivos aún más pequeños.
Con la futura adopción de HTTP 2.0 por parte de los navegadores cada vez será menos necesario, pero hoy por hoy es imprescindible conocerlo.
Algunos recursos interesantes sobre el tema:
CORS
Estándar creado por el W3C que modifica el modo de funcionamiento tradicional del objeto XmlHttpRequest (el que se usa para realizar llamadas AJAX) para dotarlo de capacidades de acceso a otros dominios. También define las convenciones necesarias para que los servidores que ofrecen servicios puedan regular el acceso de los navegadores a los mismos. La especificación se denomina Cross-Origin Resource Sharing (compartición de recursos entre diferentes orígenes) o más concisamente con el acrónimo CORS.
Muchos programadores cuando oyen hablar de CORS piensan en un protocolo de seguridad para proteger el acceso a los recursos, de manera similar a tener una clave o usar un mecanismo de cifrado o algo similar. Se trata de un error de concepto. CORS no pretende proteger el acceso a las aplicaciones de servidor. No es un método de seguridad para servicios en Internet.
Lo que busca es proteger a los usuarios frente a ataques de phishing y XSRF para que no sean víctimas de un pirata de forma inadvertida, que es algo muy diferente. Por ejemplo, que si un pirata quiere sacar partido a una vulnerabilidad XSS (Cross-Site Scripting) y usar uno de nuestros servicios desde otro dominio, no le sea posible, pero sí que se pueda utilizar desde el dominio o dominios para los que estaba pensado.
Los principales navegadores lo implementan hace bastante tiempo (Internet Explorer desde la versión 8). Según CanIUse, hoy en día su soporte es prácticamente universal:
Así que podemos usarlo sin problemas en nuestros servidores y depender de ello en la parte cliente de las aplicaciones, salvo que tengamos que soportar navegadores muy antiguos.
Si te interesa puedes leer el estándar completo aquí: http://www.w3.org/TR/cors/.
JSON
Se trata de un formato ligero para intercambio de datos basado en la notación literal para objetos que posee JavaScript, basado en el estándar ECMA-262 de 1999 (¡ya tiene años!). Lo describió formalmente y lo popularizó Douglas Crockford (otro nombre que deberías conocer si trabajas con JavaScript, aunque sea por "cultura general").
En este formato los datos se representan delimitados con llaves y con parejas de nombre valor divididas por ":" y separadas por comas. Por ejemplo, esta sería la representación de los datos de una persona:
{
"nombre": "José Manuel",
"apellidos": "Alarcón Aguín",
"edad": 42,
"estatura": 1.79,
"direccion": {
"calle": "Avenida de Madrid",
"numero": 18,
"ciudad": "Vigo"
}
}
Como vemos es un formato fácil de entender. Aquí podemos ver estos mismos datos representados en forma jerárquica con el excelente visor de JSON on-line de Turi Gabor:
Las principales ventajas de este formato son:
- Es fácil de leer (y escribir) para los programadores, como acabamos de ver.
- Al estar basado en JavaScript es directo para un navegador procesarlo y utilizarlo, de modo que no añade complejidad alguna al proceso cuando se reciben o se envían al servidor.
- Ocupa mucho menos que XML, el formato tradicionalmente utilizado para intercambio de datos en Internet, ya que no hace uso de etiquetas. Por eso ayuda a ahorrar ancho de banda y a crear aplicaciones más rápidas.
En la página oficial del formato se puede aprender sobre él y conseguir bibliotecas para su uso desde casi cualquier entorno o lenguaje de programación imaginable.
REST
REST es el acrónimo de Representational State Transfer, o lo que es lo mismo en español: Transferencia de Estado Representacional. Seguro que con esto te has quedado como estabas ;-)
Se refiere a una arquitectura de software para diseñar aplicaciones cliente-servidor. Se basa en la existencia de un protocolo de comunicaciones entre clientes y servidores, que no utiliza estado (cada llamada es independiente de las demás) y es cacheable. En la práctica se utiliza el protocolo HTTP siempre para crear esta arquitectura, y es una alternativa a protocolos de menor nivel, más complejos, como SOAP (servicios web tradicionales basados en XML) o RPC.
Par simplificar diremos que hoy en día REST se refiere al uso de HTTP, sus verbos más comunes (GET, POST, PUT, DELETE....) así como URLs "limpias" (sin parámetros en el querystring) para realizar llamadas desde el cliente al servidor, realizando acciones sobre éste.
Una API de tipo REST es sencilla de usar y de crear, y debe cumplir básicamente 6 principios:
- Sin estado: el servidor no guarda información alguna de contexto de las llamadas, de modo que no distingue realmente entre unas y otras, y la información necesaria para dar contexto debe ir incluida en cada llamada.
- cliente-servidor: separa las responsabilidades claramente entre cliente y servidor, de modo que el código de lado cliente (por ejemplo en JavaScript) sea fácilmente transportable pues no tiene que preocuparse de cuestiones como el almacenamiento por ejemplo.
- Interfaz uniforme: es quizá una de las partes más importantes de la arquitectura ya que. básicamente, dice que los recursos deben estar identificados en cada petición de manera única (con URIs), cuando se tiene un recurso identificado ya se tiene toda la información necesaria para manipularlo (se cambia el verbo HTTP para realizar acciones diferentes), las respuestas incluyen información suficiente sobre cómo se deben procesar (por ejemplo, el tipo de dato recibido)...
- Sistema en capas: un cliente realmente no tiene forma de saber si se está conectando directamente con el servidor que sirve sus peticiones de la API o éste es un servidor intermedio que enruta la verdadera petición a otro servidor. Esto último es típico en sistemas grandes que reciben muchas peticiones y deben balancear la carga entre muchos nodos.
- Cacheable: se debe indicar explícitamente si es posible o no almacenar el resultado de las peticiones, y por cuánto tiempo. De este modo se puede hacer que una misma llamada sirva para un periodo determinado y no se deba repetir, descargando gracias a ello al servidor. Esto es muy parecido a lo que ocurre con as páginas web, y se consigue de manera muy sencilla con el protocolo HTTP estándar.
- Código bajo demanda: este es opcional en realidad. Se refiere a la capacidad de modificar el comportamiento del cliente enviando desde el servidor fragmentos de código que éste debe procesar. Por ejemplo, ante una petición el servidor devuelve código JavaScript que se recibe en el navegador y se ejecuta, cambiando por lo tanto algo en el cliente (datos, la interfaz...) y no solo limitándose a recibir datos. No es muy frecuente.
En realidad todo esto que parece tan complicado es fácil de implementar y usar en la práctica.
Por regla general la mayor parte de los servicios on-line ofrecen hoy en día una interfaz de tipo REST para poder automatizarlos y sacarles partido desde aplicaciones externas. Por ejemplo Twitter, Dropbox, Google para casi todos sus servicios (por ejemplo, GMail, los calendarios o la compra-venta de anuncios), etc, etc...
Se pueden crear APIs REST de manera sencilla en casi todos los lenguajes, como Node.js con Express, en PHP o con ASP.NET Web API en entornos Microsoft, por poner algunos ejemplos.
Si vas a programar contra algún servicio es casi seguro que hoy en día acabarás usando una API REST. Si vas a exponer funcionalidad de tu aplicación al mundo, es casi seguro que acabarás creando una API de tipo REST. Así que conviene conocerlo.
Fecha de publicación: