¿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.
¿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.
¿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.
¿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.)
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
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. 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
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>
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
Top Related