View
246
Download
1
Category
Preview:
Citation preview
@dmunozgaete
Definiciones, Principios, Estándares y un poco de mi cosecha ;)!....
RESTful *Whatever
David Antonio Muñoz Gaete
Hola!, Yo soyDavidArquitecto de Soluciones – MentorEntusiasta de la tecnología, Emprendedor empedernido, y arquitecto de software de corazón ;).
Hoy particularmente feliz y haciendo del mundo, un mundo mas conectado junto con un equipo de cracks ;)!
Creador del framework RESTFul Gale
En esta oportunidad veremos: Qué es REST?
• Principio RESTFul Mejores Practicas en la creación de una API REST
• Protocolo ODATA• Seguridad basada en Token (JWT)• Versionamiento• Documentación “Viva”
Workshop Practico
RESTFul
Diseño Rapidez
Conocimiento
OD
ATA
C#Emprendimiento
Microservicios
API
ProgramaciónGALE
Servicios
Fabric
Experiencia
Soluciones
Escalable
Calidad
Qué es REST?(Y su posición en mundo TI Actual)
“Representational State Transfer”, es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP.
REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras alternativas que se han usado en los últimos diez años como SOAP y XML-RPC.
Podríamos considerar REST como un framework para construir aplicaciones web respetando HTTP.
Su posición en el mundo TI aumenta cada días mas y su utilización mas común es la construcción orientada a micro servicios.
Definición Ad-hoc
Principio RESTFul RESTFul es la implementación de la arquitectura REST en
servicios orientados a web. 4 Principios estrictos:
Uso Correcto de URI’s Uso explicito de verbos HTTP (GET, POST, PUT, DELETE, PATCH) y códigos de
estado Nunca debe mantener algún estado en el servidor. Debe responder tipos de medios de internet (Hipermedia – XML, JSON o
ambos) HATEOAS
Uso Correcto de URI’s Las acciones directas sobre una ruta web , deben ser eliminada.
Ejemplo: POST http://piik.in/v1/user/172522ec1028ab7/editPUT http://piik.in/v1/user/172522ec1028ab7
No añadir métodos personalizados si los estándares no acompañanPara todo existe una solución estándar!
Definición de URI en base a recursos (todo es un recurso), usuarios, roles, etc. Las URIs no deben implicar acciones y deben ser únicas Las URIs deben ser independientes de formato (el formato se define por content-
type)
Uso explicito de verbosPara la manipulación de los recursos: GET: Para consultar y leer
recursos POST: Para crear recursos PUT: Para editar recursos DELETE: Para eliminar
recursos. PATCH: Para editar partes
concretas de un recurso.
GET /users -> Lista los usuariosPOST /users -> Crea un usuarioPUT /users/123 -> Edita al usuarioDELETE /users/123 -> Elimina el usuarioPATCH /users/123 -> Modificar cierta información del usuario.
Uso de Códigos de EstadoAl NO usar códigos de estado estandarizados nos exponemos a:
No es REST ni es estándar. El cliente que acceda a este API debe conocer el funcionamiento
especial y cómo tratar los errores de la misma, por lo que requiere un esfuerzo adicional importante para trabajar con una API con errores personalizados.
Tenemos que preocuparnos por mantener nuestros propios códigos o mensajes de error, con todo lo que eso supone.
Insostenible en el tiempo , debido a que se debe implementar una buena documentación que describa todos los tipos de errores.
Uso de Códigos de EstadoCódigos estándar mas usados:Código HTTP Operación Descripción
200 OK GET, PUT, DELETE Resource
No error, operation successful
201 Created POST Resource was created
Successful creation of a resource.
204 No Content GET, PUT, DELETE N/A The request was processed successfully, but no response body is needed
400 Bad Request GET, POST, PUT, DELETE
Malformed syntax or a bad query.
401 Unauthorized GET, POST, PUT, DELETE
Action requires user authentication
403 Forbidden GET, POST, PUT, DELETE
Authentication failure or invalid Application ID.
404 Not Found GET, POST, PUT, DELETE
Resource not found.
408 Request Timeout
GET, POST Request has timed out.
500 Server Error GET, POST, PUT Internal server error.
501 Not Implemented
POST, PUT, DELETE Requested HTTP operation not supported.
No mantiene estadoUna aplicación o cliente de servicio web REST debe incluir dentro del encabezado y del cuerpo HTTP de la petición todos los parámetros, contexto y datos que necesita el servidor para generar la respuesta.
En Resumen: Se debe Eliminar TODO componente de sesión o almacenamiento de variables especificas de usuario o de contexto en el lado del servidor o API!.
Ventajas: El no mantener estado mejora el rendimiento de los servicios web y simplifica el
diseño e implementación de los componentes del servidor, ya que la ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.
Soporte a Tipos de MediosLa última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas. Acá es donde realmente vale la pena mantener las cosas simples, legibles por humanos, y conectadas.Tipo de formato Requerido Encabezado Content-Type
JSON application/jsonXML application/xmlXHTML application/xhtml+xml
HATEOAS (Hypermedia As The Engine Of Application State)
Significa algo así como que, dado un endpoint de nuestra API REST, podemos ser capaces de descubrir sus recursos basándonos únicamente en las respuestas del servidor.
parte de la información devuelta serán identificadores únicos en forma de hipervínculos a otros recursos asociados.
123
Request URL: http://piik.in/v1/users/10Method: GETStatus Code: 200 OK
{ "id": 10, "nombre": ”David", ”roles": [ { "id": 10 }, { "id": 11 } ]}
{ "id": 10, "nombre": ”David", ”roles": [ { ”role": "http://piik.in/v1/roles/10" }, { ”role": "http://piik.in/v1/roles/11" } ]}Sin HATEOAS Con HATEOAS
RESTFul
Diseño Rapidez
Conocimiento
OD
ATA
C#Emprendimiento
Microservicios
API
ProgramaciónGALE
Servicios
Fabric
Experiencia
Soluciones
Escalable
Calidad
Mejores Practicas en API’s REST
(para no ponernos muuuy creativos)
ODATA (Open Data Protocol – http://www.odata.org)
Open Data Protocol, es una iniciativa impulsada por Microsoft para la exposición de datos como Servicio basándose en estándares de Internet como RESTFul
La creación de una forma uniforme de representación de datos estructurados a través de Atom o JSON (JavaScript Object Notación)
La utilización de convenciones URL uniformes tanto para la navegación, filtrado, orden y paginación de datos (entre otros)
Un formato de consulta estándar para endpoints REST
GET http://piik.in/v1/Users?$limit=10&$offset=0&$filter=name contains ‘David’{ "offset": 0, "limit": 10, "total": 9, "elapsedTime": "00:00:00.0570876", "items": [ { "token": "30e517b6-5f76-4fd3-8668-fefae56c8519", "createdAt": "2016-02-27T12:30:43.65-03:00", "email": ”dmunozgaete@gmail.com", ”name": ”David Antonio Muñoz Gaete” }, { "token": "30e517b6-5f76-4fd3-8668-fefae56c8519” ….......
Autenticación basada en Token Recomendada para servicios sin estado
(RESTFul) El funcionamiento es el siguiente:
El usuario se autentica en nuestra aplicación, bien con un par usuario/contraseña, o a través de un proveedor como puede ser Twitter, Facebook o Google.
El servidor envía un Token de Identificación Cada petición HTTP que haga el usuario va
acompañada de un Token en la cabecera. Este Token no es más que una firma cifrada
que permite a nuestro API identificar al usuario y se almacena en el lado del Cliente
Versionamiento Siempre versiona tu API. El versionado te ayuda a iterar más rápido y evitar peticiones
inválidas desde endpoints actualizados. Además te ayuda a resolver cualquier transición importante de versión de la API mientras continúas ofreciendo versiones no actualizadas por un período de tiempo.
Request URL: http://piik.in/v1/users/10Request Method: GETStatus Code: 200 OK
Request URL: http://piik.in/v2/users/10Request Method: GETStatus Code: 200 OKVersión 1 Versión 2
Documentación “Viva” y en línea “No existen las obviedades” Siempre una buena
documentación nos permite evitar el caos y la desorganización.
Es fome pero necesaria =/. Hay varios formatos de
documentación RESTFul, el mas usado es Swagger
Haga clic en el icono para
agregar una imagen
Pro Tip: Gale implementa de forma “nativa” todo lo que hemos visto hasta ahora.
RESTFul
Diseño Rapidez
Conocimiento
OD
ATA
C#Emprendimiento
Microservicios
API
ProgramaciónGALE
Servicios
Fabric
Experiencia
Soluciones
Escalable
Calidad
Workshop Practico(metiendo manos…)
Instalación Demosmothership$: git clone https://github.com/dmunozgaete/demo-restful.git mothership$: cd Demosmothership$: npm installmothership$: bower installmothership$: grunt lift
Puedes seguir mis aventuras en:
Gracias por tu tiempo!
https://github.com/dmunozgaete
https://twitter.com/DMunozGaete
https://cl.linkedin.com/in/dmunozgaete
Gale RESTFul API FrameworkEsta presentación no hubiera sido lo mismo sin:
David Muñoz Gaete
Arquitecto de SoftwareMentor Técnico
Emprendedor
Recommended