Capacitación formadores Generación de

capacidades en el Ecosistema Digital de

Bogotá

Formación especializada TI
 AJAX
Asynchronous JavaScript And XML
AJAX
es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications).
Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se
mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible
realizar cambios sobre las páginas sin necesidad de recargarlas, mejorando la interactividad, velocidad
y usabilidad en las aplicaciones.

Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se solicitan al servidor y se
cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página, aunque
existe la posibilidad de configurar las peticiones como síncronas de tal forma que la interactividad de la
página se detiene hasta la espera de la respuesta por parte del servidor.
 JSON
JavaScript Object Notation
JSON
acrónimo de JavaScript Object Notation, es un formato de texto ligero para el
intercambio de datos. JSON es un subconjunto de la notación literal de objetos
de JavaScript aunque hoy, debido a su amplia adopción como alternativa a XML,
se considera un formato de lenguaje independiente.

Una de las supuestas ventajas de JSON sobre XML como formato de

intercambio de datos es que es mucho más sencillo escribir un analizador
sintáctico (parser) de JSON. En JavaScript, un texto JSON se puede analizar
fácilmente usando la función eval(), lo cual ha sido fundamental para que JSON
haya sido aceptado por parte de la comunidad de desarrolladores AJAX, debido
a la ubicuidad de JavaScript en casi cualquier navegador web.
API REST
API REST
En la actualidad no existe proyecto o aplicación que no disponga de una API
REST para la creación de servicios profesionales a partir de ese software.
Twitter, YouTube, los sistemas de identificación con Facebook… hay cientos de
empresas que generan negocio gracias a REST y las APIs REST. Sin ellas, todo el
crecimiento en horizontal sería prácticamente imposible. Esto es así porque
REST es el estándar más lógico, eficiente y habitual en la creación de APIs para
servicios de Internet.
API REST
Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que
use HTTP para obtener datos o generar operaciones sobre esos datos en todos
los formatos posibles, como XML y JSON.
Características de REST
● Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la
información necesaria para ejecutarla, lo que permite que ni cliente ni
servidor necesiten recordar ningún estado previo para satisfacerla.
● Las operaciones más importantes relacionadas con los datos en cualquier
sistema REST y la especificación HTTP son cuatro: POST (crear), GET (leer y
consultar), PUT(editar) y DELETE (eliminar).
● Los objetos en REST siempre se manipulan a partir de la URI. Es la URI y
ningún otro elemento el identificador único de cada recurso de ese sistema
REST.
Características de REST
● Interfaz uniforme: para la transferencia de datos en un sistema REST, este
aplica acciones concretas (POST, GET, PUT y DELETE) sobre los recursos,
siempre y cuando estén identificados con una URI.
● Sistema de capas: arquitectura jerárquica entre los componentes. Cada una
de estas capas lleva a cabo una funcionalidad dentro del sistema REST.
● En el caso de una API REST, el concepto de hipermedia explica la capacidad
de una interfaz de desarrollo de aplicaciones de proporcionar al cliente y al
usuario los enlaces adecuados para ejecutar acciones concretas sobre los
datos.
HATEOAS
Para cualquier API REST es obligatorio disponer del principio HATEOAS
(Hypermedia As The Engine Of Application State - Hipermedia Como Motor del
Estado de la Aplicación) para ser una verdadera API REST. Este principio es el
que define que cada vez que se hace una petición al servidor y éste devuelve una
respuesta, parte de la información que contendrá serán los hipervínculos de
navegación asociada a otros recursos del cliente.
Formularios con AJAX en Rails
Cuando creamos un Scaffold el por defecto nos agrego la función respond_to en
el controlador y sobre este entrega dos respuestas una HTML y una Json.
Dependiendo de la solicitud recibida desde el formulario el entregara alguna de
estas respuestas. Para indicarle que la petición va a ser asíncrona debemos
agregar al formulario la propiedad remote con valor true

.
Json builder
Cuando generamos el scaffold adicionalmente en las vistas nos genero unos
archivos con la extensión jbuilder. Estos básicamente nos ayudan a mostrar el
resultado de nuestras peticiones en Json para que pueden ser consumidas
desde otra aplicación.

Para que por ejemplo podamos consumir los comentarios de una tarea debemos
nuevamente crear el método show, automáticamente cuando se realice una
petición remota(Ajax) el controlador entregara la respuesta en la vista
show.json.jbuilder.
Jbuilder
Si analizamos la vista _comentario.json.jbuilder vemos que usa un método
llamado extract! Que básicamente me analiza el objeto y lo vuelve json, sin
embargo podríamos modificarlo para establecer algun orden especifico o
agregar más campos a nuestro json.
JSON Web Token
(JWT) es un estándar abierto (RFC-7519) basado en JSON para crear un token
que sirva para enviar datos entre aplicaciones o servicios y garantizar que sean
válidos y seguros.
El caso más común de uso de los JWT es para manejar la autenticación en
aplicaciones móviles o web. Para esto cuando el usuario se quiere autenticar
manda sus datos de inicio del sesión al servidor, este genera el JWT y se lo
manda a la aplicación cliente, luego en cada petición el cliente envía este token
que el servidor usa para verificar que el usuario este correctamente autenticado
y saber quien es.
knock
Knock es una solución de autenticación para la aplicación Rails API-only basada
en JSON Web Tokens.
¿Por qué se recomienda?
● Es liviano
● Está diseñado para la aplicación Rails API-only.
● Es sin estado .
● Funciona de la caja con Auth0 .
¿Por qué no un cookie?
Por definición, los API de arquitectura REST no tienen una noción de estado del
cliente, es decir que distintos clientes pueden acceder al API y sus respectivos
estados no tienen injerencia en los procesos internos del API. En el caso de los
cookies, esto no ocurre pues una sesión tiene que ser creada por cada cliente en
el servidor y almacenada en una base de datos. El cliente a su vez debe guardar
la identificación de la sesión para poder comunicarse con el servidor. Los
navegadores se encargan de guardar estas identificaciones. Si los únicos
clientes de un API fuesen los navegadores, esto podría funcionar medianamente
bien a pesar de la carga extra a la base de datos aunque no sería un API REST.
Crear Proyecto API en Rails
Ejecutemos el comando para iniciar una nueva aplicación en Rails en modo API.

rails new mi_api --api

Va a crear una nueva aplicación de Rails solo-API llamado mi_api. No olvides que
el soporte para la opción --api fue agregada solo en Rails 5, así que asegúrate de
que tienes esta o una versión más nueva instalada.

Abre el Gemfile y nota que es mucho más pequeño de lo habitual: gemas como
coffee-rails, turbolinks y sass-rails no están.
El archivo config/application.rb contiene una nueva línea:
config.api_only = true

Significa que Rails va a cargar un conjunto más pequeño de intermediario: por ejemplo, no hay soporte
de cookies ni sesiones. Más aún, si tratas de generar un andamio, las vistas y recursos no serán
creados. Actualmente, si revisas el directorio views/layouts, notarás que el archivo application.html.erb
también falta.

Otra diferencia importante es que ApplicationController hereda de ActionController::API, no

ActionController::Base.

Esto es prácticamente todo, esta es la aplicación básica de Rails que has visto muchas veces.
Agregar algunas gemas
# Esta gema nos permite habilita "has_secure_password" en Active Record
gem 'bcrypt', '~> 3.1.7'

# Usamos Rack CORS para habiliar Cross-Origin Resource Sharing (CORS)

gem 'rack-cors'

# Usamos knock para autenticar con el JWT

gem 'knock'

# Usamos Active Model Serializers para definir las respuestas del API en JSON
gem 'active_model_serializers', '~> 0.10.0'
Crear entidad
Vamos a hacer un ejemplo muy sencillo simplemente vamos a crear un modelo
User el cual vamos a consultar por medio de nuestra API

rails generate scaffold User name:string email:string password_digest:string

rails db:migrate
Knock para autenticar con JWT
Como ya incluimos la gema en un inicio, sólo nos queda usar el generador para
instalar knock en la aplicación:

rails generate knock:install

Integrando Knock al modelo User
A continuación generamos el controlador con la acción necesaria para la
autenticación. El generador también se encarga de agregar la ruta necesaria en
el archivo config/route.rb.

rails generate knock:token_controller user

Ahora debemos incluir “has_secure_password” en nuestro modelo para indicar
que queremos usar BCrypt para verificar contraseña con la contraseña
encriptada en la base de datos. La gema bcrypt se encarga de la encriptación, el
único requisito previo es incluir el atributo “password_digest”, lo cual ya hicimos
al generar nuestro modelo.
Definiendo el modelo User
Protejamos a nuestros controladores
Primero, hagamos que nuestros controladores tengan la habilidad de ser
autenticables a través de Knock:
Ahora, en un REST API pueden haber entidades y métodos que requieren
autenticación y otros que no. A continuación veamos como exigir autenticación
para una sólo acción en el controlador:
Cabe destacar que en la función user_params, en dónde se genera una lista
blanca de los campos que pueden ser modificados,
remplazamos :password_digest por :password y :password_confirmation.
Habilitar CORS
Cross-Origin Resource Sharing (CORS), se refiere a la habilidad de compartir
recursos de un dominio a otro. Esto puede ser vídeos, imágenes, hojas de estilo,
etc. Sin embargo, debido a la política del mismo origen los navegadores no
pueden realizar solicitudes AJAX desde el documento actual (léase página
actual) a otro documento pero que pertenezca a un dominio distinto. De modo
que un API debe habilitar específicamente que dominios pueden acceder al API.
Si es un API público entonces se puede habilitar a cualquier dominio. En nuestro
caso habilitaremos a todos los dominios debido a que no queremos
restricciones para probar nuestro API desde cualquier dominio, incluyendo
nuestro “localhost”.
Vamos al archivo config/cors.rb y descomentamos las opciones que
necesitamos:
Respuesta HTTP en JSON
Para esto ya incluimos en inicio la gema active_model_serializers. Por defecto va
a incluir todos los campos de la migración (db/migrate/*_create_users.rb), pero
vamos a retirar cualquier mención del atributo “password” (contraseña).
Probemos nuestra API
Crear un usuario
Consultar usuario
Retoques finales
Vamos a agregar un “endpoint” más para obtener la información del usuario
actual: /users/current

Para esto agreguemos la acción en el controlador:

Agregar nuestra ruta en el archivo routes.rb:
Autenticarnos
Para autenticarnos, vamos a enviar las credenciales de nuestro usuario al método user_token. La
respuesta será el token que debemos usar para hacer uso de toda nuestra api.
Consultar usuarios
Ahora que ya estamos autenticado si podemos usar nuestro token para
consultar usuarios.
Agreguemos más modelos
rails g scaffold Articulo titulo:string contenido:text user:belongs_to
Probar agregar nuevos elementos
Si enviamos una solicitud sin el token nos responderá con código 401 Unauthorized