Facultad de Estadística e Informática

TECNOLOGIAS PARA LA INTEGRACION DE SOLUCIONES

Facultad de Estadística e Informática

Clase 22

▪ Tema 4: Servicios Web RESTful

Introducción¿QUÉ ES UN SERVICIO WEB?

¿Qué es un Servicio Web?

◦ El consorcio W3C define los Servicios Web como sistemas software diseñados para soportar una interacción interoperable maquina a maquina sobre una red.◦ Esta definición de Servicios Web alberga muchos tipos diferentes de sistemas,

pero los estudiados en el curso se han referido a los clientes y servidores que se comunican mediante mensajes XML que siguen el estándar SOAP.

Sistema de información

Internet Internet

Servicio Web

Servicio Web

Servicio Web

¿Qué es un Servicio Web?

◦ Actualmente los Servicios Web suelen ser APIs (Interfaz de Programación de Aplicaciones) Web que pueden ser accedidas dentro de una red (principalmente Internet), usando un protocolo (HTTP), un formato (XML o JSON) y son ejecutados en el sistema que los aloja (servidor Web).

Sistema de información

Internet Internet

Servicio Web

Servicio Web

Servicio Web

Estilos de arquitectura de Servicios Web

◦En los últimos años los estilos de arquitectura de software han evolucionado de la siguiente manera:◦ Remote Procedure Calls o RCP. Orientado a operaciones.

◦ Arquitectura Orientada a Servicios o SOA. Orientado a mensajes.

◦ Arquitectura Orientada a Recursos o REST (Representational StateTransfer). Servicios Web implementados a través del protocolo HTTP o protocolos similares con la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (GET, POST, PUT, DELETE). Se centra en interactuar con recursos con estado, más que con mensajes y operaciones.

RPC SOA ROA

¿Por qué otro estilo REST? ¿Problemas con SOAP?

SOAP ofrece una excelente manera de trasferir datos entre aplicaciones, pero:◦Junto con los datos, muchos metadatos también necesitan ser transferidos en cada petición y respuesta.

◦Esta información extra es necesaria para conocer las capacidades del Servicios Web a consumir.

¿Por qué otro estilo REST? ¿Problemas con SOAP?

SOAP ofrece una excelente manera de trasferir datos entre aplicaciones, pero:◦Este intercambio, hace que la carga en la comunicación sea pesada aun para pequeños datos.

◦Además, los clientes necesitan crear un proxy para empaquetar y desempaquetar los mensajes SOAP usando WSDL para hacer posible la comunicación.

◦El problema con este proxy es que si el servicio es actualizado, pero el cliente no, el consumo del servicio Web no funcionará correctamente.

RESTSERVICIOS WEB REST

¿Qué es REST?

➢REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas distribuidos en la Web.

➢Se refiere a una interfaz, que consiste en una red de recursos Web relacionada por links y operaciones como GET, DELETE (transiciones de estado).

➢El término fue introducido en la tesis doctoral de Roy Rielding en 2000, quien es uno de los principales autores de la especificación HTTP.

¿Qué es REST?

➢REST no es un estándar, es un estilo de arquitectura y el término se refiere estrictamente a una colección de principios para el diseño de arquitecturas de red.

➢Estos principios resumen cómo los recursos son definidos y diseccionados.

➢Frecuentemente se utiliza para describir a cualquier interfaz que transmite datos específicos de un dominio sobre HTTP sin una capa adicional como la hace SOAP.

¿Qué es REST?

•Aunque REST no es un estándar, esta basado en estándares:•HTTP•URL•Representación de recursos: XML/HTML/JSON• Tipos de contenido MIME: text/xml, text/html,

text/json

¿Qué es REST?

Internet

Servicio Web

Servicio Web

Servicio Web

• Intenta usar todas las características de la Web para el intercambio de mensajes entre computadoras distribuidas.

• Las URIs identifican los recursos, los cuales son objetos conceptuales. La representación de tales objetos se distribuye por medio de mensajes a través de la Web.

URI

XML/JSON

Principios de REST

➢Escalabilidad de la interacción con los componentes. La Web ha crecido exponencialmente sin degradar su rendimiento.

➢Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial.

➢Puesta en funcionamiento independiente. HTTP permite la extensibilidad mediante el uso de las cabeceras, a través de las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido.

➢Compatibilidad con componentes intermedios. La compatibilidad con intermediarios (Proxys, Firewall, Cachés) nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

Elementos participantes en REST

Debido a que la Web evidentemente es un ejemplo clave de diseño basado en REST; consiste del protocolo HTTP con una interfaz uniforme para acceso a los recursos, el cuál consiste de:

URIs

Códigos de estado

Verbos HTTP

Cabeceras

Contenido guiado

por MIME

URIs

Un identificador de recursos uniforme o URI —del inglés UniformResource Identifier— es una cadena de caracteres que identifica los recursos de una red de forma unívoca.

Las “cosas” identificadas por URIs son “recursos”. Aunque es más apropiado decir que los Recursos son identificados mediante URIs.

Operación URI

Listado https://www.myserver.com/api/películas/

Detalle https://www.myserver.com/api/películas/3

Verbos HTTP

❖Los verbos más importantes en HTTP son PUT, GET, POST, DELETE.

❖ Suelen ser comparados con las operaciones asociadas a la tecnología de base de datos: CRUD: CREATE, READ, UPDATE, DELETE.

❖Otras analogías pueden también ser hechas como con el concepto de copiar-y-pegar (Copy&Paste).

Acción HTTP SQL UNIX Shell

Create PUT INSERT >

Read GET SELECT <

Update POST UPDATE >>

Delete DELETE DELETE Del/Rm

Verbos HTTP

❖Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación.

Códigos de estado

❖HTTP especifica un conjunto de códigos de estado para cadallamada.

❖Es decir, al solicitar un recurso mediante un URI, el servidor regresará un código de estado de la respuesta, por ejemplo: Éxito, Error o No encontrado.

Códigos de estado

Código de estado

Significado

200 Éxito. La respuesta incluirá información pertinente sobre el recurso

201 Recurso creado. La respuesta incluirá la URI del recurso creado.

301 El recurso se ha movido. Debe incluir la URI de la nueva ubicación.

400 Petición errónea. El cliente debe reformular la petición.

401 Sin autorización. Credenciales erróneas para acceder al recurso.

403Acceso denegado. Se ha autentificado al usuario, pero no tiene permiso de acceder al recuso.

404 Recurso no encontrado.

500Error de servidor. Algo malo pasó en el servidor. Se debe incluir algún tipo de información.

Cabeceras

❖Las Cabeceras HTTP son los parámetros que se envían en una petición o respuesta HTTP, al cliente o al servidor para proporcionar información esencial sobre la transacción en curso.

❖Estas cabeceras proporcionan información mediante la sintaxis 'Cabecera: Valor' y son enviadas automáticamente por el navegador o el servidor Web.

Cabeceras

Cabecera de petición

Ejemplo

Accept Accept: text/plain

Accept-Charset Accept-Charset: utf-8

Accept-Language Accept-Language: en-US

Cabecera de respuesta

Ejemplo

Status Status: 200 OK

Content-TypeContent-Type: text/html;

charset=utf-8

Content-Language Content-Language: en

Contenido guiado por MIME

Se refiere a los encabezados MIME media typeó content type.

Es un identificador del formato del archivo y el contenido que se transmite en Internet.

Esto permite conocer el visor apropiado para el tipo de datos del encabezado enviado.

Se compone de un tipo y un subtipo: tipo/subtipo.

MIME Type

application/javascript

application/json

application/xml

application/zip

text/css

text/html

image/jpeg

Ejemplos REST con XMLPor ejemplo la siguiente petición puede ser enviada a un servidor:

GET /api/peliculas/1234 HTTP/1.1

La respuesta del servicio:

HTTP/1.1 200 OK

Content-Type: application/xml

<Pelicula Id="1234" Status="Active" DateCreated="2017-08-19" Owner=“Erika“ Category=“Acción">

<link rel="self" href="/api/peliculas/1234" method="GET" />

<link rel=“actores" href="/api/peliculas/1234/actores" method="GET" />

<link rel=“delete" href="/api/peliculas/1234" method="DELETE" />

<link rel="update" href="/api/peliculas/1234" method="PUT" />

</Pelicula>

Ejemplos REST con XMLPor ejemplo para crear una nueva película:

POST /api/peliculas HTTP/1.1

Content-Type: application/xml

<Pelicula Status="Active" DateCreated="2017-08-15" Owner=“Erika“ Category=“Drama">

La respuesta del servicio asumiendo que se creó exitosamente:

HTTP/1.1 201 Created

Location: /api/peliculas/6789

Content-Type: application/xml

<Pelicula Id="6789" Status="Active" DateCreated="2017-08-15" Owner=“Erika" Category=“Drama">

<link rel="self" href="/api/tasks/6789" method="GET" />

<link rel="owner" href="/api/tasks/6789/owner" method="GET" />

<link rel=“delete" href="/api/tasks/6789" method="DELETE" />

<link rel="update" href="/api/tasks/6789" method="PUT" />

</Task>

¿REST vs los servicios Web estudiados anteriormente

Esta pregunta es un tanto errónea, aunque es bastante típica en los foros de discusión.

REST es un estilo, mientras que los servicios Web son sistemas software. Por tanto, no es posible la comparación de ambos conceptos.

Por otra parte, popularmente se generaliza el concepto de servicio Web con el de servicio Web basado en SOAP. Como hemos visto en apartados anteriores, es posible diseñar servicios Web basados en REST, es decir tomando REST como estilo de diseño.

Por tanto, REST no es una alternativa a los servicios Web, más bien, un servicio Web puede ser implementado mediante SOAP o basado en el estilo REST.

¿REST Vs SOAP?

❖SOAP puede ser demasiado complicado para mostrar cantidades de datos masivos.

❖Este es el caso de grandes empresas como eBay y Google.

❖El problema principal surge del propósito inicial de SOAP, pues fue originalmente pensada para ser una versión, sobre Internet, de DCOM o CORBA, modelos RPC (RemoteProcedure Call) .

¿REST Vs SOAP?

❖Son más adecuadas para entornos aislados, es decir, entornos perfectamente conocidos.

❖Pero cuando el número de usuarios es muy grande es necesario emplear una estrategia diferente. Protocolos basados en RPC no son adecuados para este tipo de sistemas, ya que cambiar su interfaz resulta complicado.

❖Por esta razón, se intenta tomar como modelo a la Web.

¿REST Vs SOAP?REST SOAP

Características Las operaciones se definen en los mensajes. Una dirección única para cada instancia del proceso. Cada objeto soporta las operaciones estándares definidas. Componentes débilmente acoplados.

Las operaciones son definidas como puertos WSDL. Dirección única para todas las operaciones. Múltiple instancias del proceso comparten la misma operación. Componentes fuertemente acoplados.

Ventajas Bajo consumo de recursos. Las instancias del proceso son creadas explícitamente. El cliente no necesita información de enrutamiento a partir de la URI inicial. Los clientes pueden tener una interfaz “listener” (escuchadora) genérica para las notificaciones. Generalmente fácil de construir y adoptar.

Fácil (generalmente) de utilizar. La depuración es posible. Las operaciones complejas pueden ser escondidas detrás de una fachada. Envolver APIs existentes es sencillo.Incrementa la privacidad. Herramientas de desarrollo.

¿REST Vs SOAP?REST SOAP

Desventajas Gran número de objetos. Manejar el espacio de nombres (URIs) puede ser engorroso. La descripción sintáctica/semántica muy informal (orientada al usuario). Pocas herramientas de desarrollo.

Los clientes necesitan saber las operaciones y su semántica antes del uso. Los clientes necesitan puertos dedicados para diferentes tipos de notificaciones.Las instancias del proceso son creadas Implícitamente.

Punto de vista La Web es el universo de la información accesible globalmente.

La Web es el transporte universal de Mensajes.

Tecnología Interacción dirigida por el usuario por medio de formularios. Pocas operaciones con muchos recursos.Mecanismo consistente de nombrado de recursos (URI). Se centra en la escalabilidad y rendimiento a gran escala para sistemas distribuidos hipermedia.

Flujo de eventos orquestados. Muchas operaciones con pocos recursos. Falta de un mecanismo de nombrado. Se centra en el diseño de aplicaciones distribuidas.

¿REST Vs SOAP?REST SOAP

Protocolo HTTPXML autodescriptivo. HTTP. HTTP es un protocolo de aplicación. Síncrono.

SOAPTipado fuerte, XML Schema. Independiente del transporte.HTTP es un protocolo de transporte. Síncrono y Asíncrono.

Descripción del servicio

Confía en documentos orientados al usuario que define las direcciones de petición y las respuestas. Interactuar con el servicio supone horas de testeado y depuración de URIs. No es necesario el tipado fuerte, si ambos lados están de acuerdo con el contenido.

WSDL. Se pueden construir automáticamente stubs (clientes) por medio del WSDL. Tipado fuerte.

Gestión del estado

El servidor no tiene estado (stateless). Los recursos contienen datos y enlaces representando transiciones a estados válidos.Los clientes mantienen el estado siguiendo los enlaces.

El servidor puede mantener el estado de la conversación. Los mensajes solo contienen datos.Los clientes mantienen el estado suponiendo el estado del servicio.

¿REST Vs SOAP?

REST SOAP

Seguridad HTTPS. Implementado desde hace muchos años. Comunicación punto a punto segura.

WS-Security. Las implementaciones están comenzando a aparecer ahora. Comunicación origen a destino segura.

Metodología de diseño

Identificar recursos a ser expuestos como servicios. Definir URLs para direccionarlos. Distinguir los recursos de solo lectura (GET) de los modificables (POST,PUT,DELETE).Implementar e implantar el servidor Web.

Listar las operaciones del servicio en el documento WSDL. Definir un modelo de datos para el contenido de los mensajes. Elegir un protocolo de transporte apropiado y definir las correspondientes políticas de calidad del servicio, de seguridad y transaccional.Implementar e implantar el contenedor del servicio Web.

¿Cómo diseñar un Servicio Web basado en REST?

1. Identificar todas las entidades conceptuales que se desean exponer como servicio.

2. Crear una URL para cada recurso. Los recursos deberían ser nombres, no verbos (acciones).

Por ejemplo no utilizar esto:

http://www.service.com/entities/getEntity?id=001

Como podemos observar, getEntity es un verbo.

Mejor utilizar el estilo REST, un nombre: http://www.service.com/entities/001

¿Cómo diseñar un Servicio Web basado en REST?

1. Categorizar los recursos de acuerdo con si los clientes pueden obtener un representación del recurso o si pueden modificarlo. Para el primero, debemos hacer los recursos accesibles utilizando un HTTP GET. Para el último, debemos hacer los recursos accesibles mediante HTTP POST, PUT y/o DELETE.

2. Todos los recursos accesibles mediante GET no deberían tener efectos secundarios. Es decir, los recursos deberían devolver la representación del recurso.

¿Cómo diseñar un Servicio Web basado en REST?

3. Ninguna representación debería estar aislada. Es decir, es recomendable poner hipervínculos dentro de la representación de un recurso para permitir a los clientes obtener más información.

4. Especificar el formato de los datos de respuesta mediante un esquema (DTD, W3C Schema, ...). Para los servicios que requieran un POST o un PUT es aconsejable también proporcionar un esquema para especificar el formato de la respuesta.

5. Describir como nuestro servicio ha de ser invocado, mediante un documento WSDL/WADL o simplemente HTML.

Microsoft ASP.NET Web APIIMPLEMENTANDO REST

¿Qué es ASP.NET Web API?

❖HTTP no es solo para servir páginas Web.

❖También es una plataforma para construir APIs que exponen servicios y datos.

❖Casi cualquier plataforma tiene una biblioteca HTTP, por lo que servicios HTTP pueden alcanzar un gran rango de clientes, incluidos navegadores, dispositivos móviles y aplicaciones de escritorio tradicionales.

ASP.NET Web API es una Framework que facilita la creación de servicios RESTful que son capaces de proveer servicios

completamente orientados a recursos.

Alternativas de otras compañías

RESTful Web Services in Javahttps://jersey.java.net/

Alternativas de otras compañías

Slim es un micro framework de PHP paradesarrollar aplicaciones Web y APIs.

ASP .NET WEB API UTILIZA MVC PARA IMPLEMENTAR SERVICIOS WEB

¿Qué es MVC?

◦ Patrón de arquitectura de software que separa el modelo, la interfaz de usuario y el control de la lógica de una aplicación en tres distintos componentes.

◦ Presentado por Trygve Reenskaug en 1979 para el Framework Smaltalk(utilizada para crear las interfaces de Apple Lisa y Macintosh).

Modelo

VistaControlador

Patrón de MVC

◦MVC propone la construcción de tres distintos componentes:

1. Modelo

2. Vista

3. Controlador

Modelo

VistaControlador

ACTUALIZA MANIPULA

MUESTRA UTILIZA

Patrón de MVC

El modelo

Representación de los datosLógica del negocioObtiene y almacena datos en un almacenamiento persistente(Base de Datos)

La vista

Interfaz de usuario a partir del modeloElementos de interacción(HTML, XML)

El controlador

Maneja la interacción con el usuario e invoca cambios al Modelo y Vistas.Intermediario entre el Modelo y la Vista.

Jerarquía de dependencia en MVC

El modelo

El Modelo solo conoce sobre el mismo.Esto quiere decir, que el código fuente del Modelo no hace referencias ni a la Vista o al Controlador.

La vista

La Vista si conoce al Modelo. Preguntará al Modelo sobre su estado para saber que mostrar.De esta manera, la Vista puede desplegar algo que esta basado en lo que el Modelo ha hecho.La Vista no sabe nada del Controlador.

El controlador

Conoce al Modelo y a la Vista.Si el usuario realiza una acción, el Controlador sabe que función en el Modelo llamar y también sabe que Vista mostrar al usuario.

Beneficios de MVC➢Fácil de manejar la complejidad

➢Desarrollo de aplicaciones más rápido

➢Reusabilidad del código

➢Desarrollo en paralelo

➢Facilita la presentación de información de diferentes maneras donde el código de la aplicación no se ve afectado

➢Ideal para sistemas grandes y distribuidos

➢Gran control sobre el comportamiento de la aplicación

Flujo de MVC

1. El usuario realiza una acción en la interfaz (ej. presiona un botón)

2. El Controlador toma el evento o acción de entrada

3. El Controlador notifica la acción al Modelo, la cuál pudiera involucrar un cambio en el Modelo (ej. edición de datos).

4. Esto genera una nueva Vista que se envía al usuario. La Vista toma los datos del Modelo (ej. lista de usuarios).

5. La interfaz de usuario espera por otra interacción de usuario, lo que inicia un nuevo ciclo.

¿Donde podemos usarlo?Prácticamente esta disponible en toda clase de sistemas y tecnologías (Java, Ruby, Python, Perl, PHP, Flex, Net, etc.)

EjemploMICROSOFT ASP.NET WEB API

WEB API PARA DEVOLVER UNA LISTA DE PRODUCTOS

Ejemplo Web API ASP.NET

ProductsApp

Ejemplo Web API ASP.NET

Ejemplo Web API ASP.NET

Product

Ejemplo Web API ASP.NET

using System;using System.Collections.Generic;using System.Linq;using System.Web;

namespace ProductsApp.Models{

public class Product{

public int Id { get; set; }public string Name { get; set; }public string Category { get; set; }public decimal Price { get; set; }

}}

Se agregan las siguientes propiedades a la clase Product

Ejemplo Web API ASP.NET

Ejemplo Web API ASP.NET

Ejemplo Web API ASP.NET

Ejemplo Web API ASP.NET

Código para ProductsController

using ProductsApp.Models;using System;using System.Collections.Generic;using System.Linq;using System.Net;using System.Net.Http;using System.Web.Http;

namespace ProductsApp.Controllers{

public class ProductsController : ApiController{

Product[] products = new Product[]{

new Product { Id = 1, Name = "Tomato Soup", Category = "Groceries", Price = 1 },new Product { Id = 2, Name = "Yo-yo", Category = "Toys", Price = 3.75M },new Product { Id = 3, Name = "Hammer", Category = "Hardware", Price = 16.99M }

};

public IEnumerable<Product> GetAllProducts(){

return products;}

public IHttpActionResult GetProduct(int id){

var product = products.FirstOrDefault((p) => p.Id == id);if (product == null){

return NotFound();}return Ok(product);

}

}}

Ejemplo Web API ASP.NET

Ejecutar el proyecto:

http://localhost:52438/api/products

http://localhost:52438/api/products/2

Ejemplo Web API ASP.NET

Ejemplo Web API ASP.NET. Llamando la Web API con Javascript y jQuery

Se agregará una página HTML que usa AJAX (Asynchronous JavaScript And XML) para llamar la Web API.

Se empleará jQuery para que AJAX llame y actualice la página con los resultados.

Ejemplo Web API ASP.NET

Ejemplo Web API ASP.NET

Index.hmtl

Ejemplo Web API ASP.NET

Código para index.html

<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head>

<title>Product App</title></head><body>

<div><h2>All Products</h2><ul id="products" />

</div><div>

<h2>Search by ID</h2><input type="text" id="prodId" size="5" /><input type="button" value="Search" onclick="find();" /><p id="product" />

</div>

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-2.0.3.min.js"></script><script>var uri = 'api/products';

$(document).ready(function () {// Envía una solicitud AJAX$.getJSON(uri)

.done(function (data) {// Si se tiene éxito, 'data' contiene la lista de productos.$.each(data, function (key, item) {

// Agrega un item de lista para el producto. La respuesta contiene un array de objetos JSON

$('<li>', { text: formatItem(item) }).appendTo($('#products'));});

});});

function formatItem(item) {return item.Name + ': $' + item.Price;

}

function find() {var id = $('#prodId').val();//´Se usa getJSON para enviar la solicitud AJAX, pero se coloca el ID solicitado en el URI

$.getJSON(uri + '/' + id).done(function (data) { //Si se tiene éxito la respuesta es la representación JSON de un

solo producto$('#product').text(formatItem(data));

}).fail(function (jqXHR, textStatus, err) {$('#product').text('Error: ' + err);

});}</script>

</body></html>

Ejemplo Web APIASP.NET

Usando jQuery

<script>var uri = 'api/products';

$(document).ready(function () {// Envía una solicitud AJAX$.getJSON(uri)

.done(function (data) {// Si se tiene éxito, 'data' contiene la lista de productos.$.each(data, function (key, item) {// Agrega un item de lista para el producto. La respuesta contiene un array

de objetos JSON$('<li>', { text: formatItem(item) }).appendTo($('#products'));

});});

});

function formatItem(item) {return item.Name + ': $' + item.Price;

}

function find() {var id = $('#prodId').val();//´Se usa getJSON para enviar la solicitud AJAX, pero se coloca el ID solicitado en

el URI$.getJSON(uri + '/' + id)

.done(function (data) { //Si se tiene éxito la respuesta es la representación JSON de un solo producto

$('#product').text(formatItem(data));}).fail(function (jqXHR, textStatus, err) {$('#product').text('Error: ' + err);

});}</script>

Ejemplo Web API ASP.NET

Gracias por su atención

ReferenciasASP.NET MVC 4 and the Web API. (diciembre de 2012). Jaime Kurtz. aPress. Obtenido de: http://sd.blackball.lv/library/ASP.NET_MVC_4_and_the_Web_API.pdf

REST Vs Web Services (2006). Rafael Navarro. Modelado, Diseño e Implementación de Servicios Web. Obtenido de: http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf

RESTful Web Services(2007). Leonard Richarson & Sam Ruby. O’Really. Obtenido de: https://www.crummy.com/writing/RESTful-Web-Services/RESTful_Web_Services.pdf

Getting Started with ASP.NET Web API 2. (2015). Mike Watson. Microsoft Docs. Obtenido de: https://docs.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api