2. 1. ¿Por qué la necesidad de RESTFull?
2. ¿Qué es RESTFull?
3. Los 6 conceptos de RESTFull
4. Como implementar RESTFull en Asp.net Core
5. Conclusión
¿Qué vamos a ver?
3. Las 8 Falacias de la Computación Distribuida
1. La red es confiable
2. La latencia es cero, la latencia no es problema
3. El ancho de banda es infinito
4. La red es segura
5. La topología no cambia
6. Hay uno y sólo un administrador
7. El coste de transporte es cero
8. La red es homogénea http://www.rgoarchitects.com/Files/fallacies.pdf
17. [HttpGet("{id}")]
public User Get(int id)
[HttpGet("{id}/comments")]
public User Get(int id)
[HttpGet("{id:int}/comments/{commentId:int}")]
public List<Comment> Get(int id,int commentId)
[HttpPost]
public void Post([FromBody]string value)
[HttpPut("{id}")]
public void Put(int id, [FromBody]string value)
Microsoft.AspNetCore.Mvc
29. Cliente 1 Cliente 2 API
G E T api/authors/{id}
G E T api/authors/{id}
PUT api/authors/{id}
Concurrencia
PUT api/authors/{id}
30. Cliente 1 Cliente 2 API
Concurrencia en RESTFull
G E T api/authors/{id}
PUT api/authors/{id}
If-Match: “123456789”
2 0 0 Ok, ETag: “123456789”
G E T api/authors/{id}
200/204, ETag: “987654321”
PUT api/authors/{id}
If-Match: “123456789”
412 Precondition failed
2 0 0 Ok, ETag: “123456789”
34. RESUMEN
• No toda api es una api RESTFull
• Debemos diseñar siempre pensando en nuestros clientes
• No debemos forzar la implementación de RESTFull
• RESTFull prepara nuestras API para el futuro
35. Recursos
Microsoft REST API Guidelines
https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md
Asp.net Core
https://docs.microsoft.com/en-us/aspnet/core/
Roy T. Fielding's dissertation
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Como armar el Etag no es parte de la norma si no que lo decide el servidor.
En 1994
L. Peter Deutsch fundador de Aladdin Enterprises y más conocido como el creador de Ghostscript, afirmó que todo programador que empieza en el mundo de las aplicaciones distribuidas comete una serie de presunciones erróneas cuyo resultado se traduce en errores o reducciones substanciales del alcance del sistema. Estas presunciones, que inicialmente fueron 7, se conocen como las Falacias de la Computación Distribuida.
Intenta definir y mostrar como una web bien diseñada se comporta por detrás.
Se diseña pensando en el modelo no en los requisitos de sismtea
Esto permite crecer y extender nuestro sistema
Se diseña pensando en el modelo no en los requisitos de sismtea
Esto permite crecer y extender nuestro sistema
Es una forma de pensar nuestras aplicaciones
Es un modelo de arquitectura
Solo se implementa sobre HTTP
Un concepto que intenta describir como se comporta la web por detrás, o como deberia comportarse por completo
En 1994
L. Peter Deutsch fundador de Aladdin Enterprises y más conocido como el creador de Ghostscript, afirmó que todo programador que empieza en el mundo de las aplicaciones distribuidas comete una serie de presunciones erróneas cuyo resultado se traduce en errores o reducciones substanciales del alcance del sistema. Estas presunciones, que inicialmente fueron 7, se conocen como las Falacias de la Computación Distribuida.
Clava diferenciadora
Aplicar patrones de diseño general, donde la Interface de nuestra api sea lo mas natural
Definir una comunicación estándar, donde todos los clientes puedan comunicarse.
No se trabaja con el recurso directamente si no con una reprensetacion de el: json, xml
Mensajes deben tener la capacidad de auto describir, los puntos de actualizacion y hasta como eliminar a este recurso (HATEOAS)
Beneficios:
Todos entienden el mismos lenguaje, y pueden reaccionar antes errores de red, o de otro tipo
Reconoce que todo se escribe en lenguajes distintos
Asegura que no se necesita que los componentes conozcan el lenguaje del otro componente, si no que entiendan un lenguaje comun independiente a su implementación
Visibilidad, el mismos mensaje significa lo mismo en todos los componentes
Estabilidad : puedo evolucionar componentes independientes sin que el sistema se vuelva inestable
Define toda la comunicación entre servidores como la de un cliente con un servidor
Separacion de responsabilidades entre cliente y servidor
Evolucion independiente
Los clientes solo conocen a los SERVIDORES y no los servidores a los CLIENTES
Portabilidad de clientes
Evolucion independiente
Clava diferenciadora
Aplicar patrones de diseño general, donde la Interface de nuestra api sea lo mas natural
Definir una comunicación estándar, donde todos los clientes puedan comunicarse.
No se trabaja con el recurso directamente si no con una reprensetacion de el: json, xml
Mensajes deben tener la capacidad de auto describir, los puntos de actualizacion y hasta como eliminar a este recurso (HATEOAS)
Beneficios:
Todos entienden el mismos lenguaje, y pueden reaccionar antes errores de red, o de otro tipo
Reconoce que todo se escribe en lenguajes distintos
Asegura que no se necesita que los componentes conozcan el lenguaje del otro componente, si no que entiendan un lenguaje comun independiente a su implementación
Visibilidad, el mismos mensaje significa lo mismo en todos los componentes
Estabilidad : puedo evolucionar componentes independientes sin que el sistema se vuelva inestable
No construimos una app sin estados
Todo estado del cliente se mantiene en el cliente y se envia en la solicitud
Evita sincronizacion entre servidores, y evita flujos complejos
Si la conexión se cae , no pierdo el estado ya que le estado viaja en el request
Pueden vivir app intermedias que sean capaz de aplica capas de seguridad
Visibilidad
Relaibility > si cae un servidor reinicio el workflow
Escalabilidad
Hypermedia as the Engine of Application State
La respuesta debe estar etiquetada como cacheable o no cacheable
Benefiicios de cache:
Cliente
Servidor
Intermedio
Dado que la latencia nunca es cero, evita esperar respuesta no necesarias al cliente
Ancho de banda, evita hacer pedidos no necesarios , reduce el ancho de banda..
Reconoce el tema de que no hay costos en las llamadas
Por ejemplo un mobile
El servidor puede mantener una cantidad X de cache, hasta evolucionar a un sistema mucho mas caro
Beneficios
Eficiencia
Escalabilidad: se peude escalar dado que no se consume toda la red
Performance.
Como armar el Etag no es parte de la norma si no que lo decide el servidor.
Como armar el Etag no es parte de la norma si no que lo decide el servidor.
Como armar el Etag no es parte de la norma si no que lo decide el servidor.
Como armar el Etag no es parte de la norma si no que lo decide el servidor.
El componente solo puede conocer las capas del sistema en el que vive
Esto permite agregar caches,.
Proxys.
Balanceadores de carga
Entiende que los servidores estan en constante cambio
Entiende que la red no es segura por lo que limita los contextos.
Puede administrarse mejor dado que cada persona puede administrar su propio contexto.
Escalabilidad
Manajabilidad
Cliente > proovedor > empresa > base de datos
Mas ignorada por falta de tecnología que pudiera implementarlo de una manera adecuada.
Jj, html5 y ajax lo hacen posible.
El servidor puede proveedor de código ejecutable al cliente.
Evita que el cliente tenga que escribir lógica redundante.
Problemas de seguridad, estamos descargando algo que no controlamos
Menos gente utilice la api.
Se debe aseguridad de que devolvemos valor al cliente que lo precisa pero no rompemos al cliente que no lo quiere.
Autenticación federada, me quiero loguear con facebook y el me devuelva html y js para que me redirija.
Rest no es una implementación. Rest es un concepto.
No todas las api rest son api rest, y aun menos todas las api RESTFull no son restfull.
Debemos tener en cuenta este concepto a la hora de diseñar nuestros sistemas, y debemos tener en cuenta siempre que nuestras aplicaciones son para nuestros clientes
Por lo que la implementación y la cantidad de conceptos que implementemos siempre deben ayudar a los clientes.
Asp.net Core, es un framework pensado para la nube, por lo que si queresmo aprobecharlo realmente debemos diseñar.