rest whatever

21
@dmunozgaete Definiciones, Principios, Estándares y un poco de mi cosecha ;)!.... RESTful *Whatever David Antonio Muñoz Gaete

Upload: david-munoz-gaete

Post on 09-Feb-2017

235 views

Category:

Internet


1 download

TRANSCRIPT

Page 1: Rest whatever

@dmunozgaete

Definiciones, Principios, Estándares y un poco de mi cosecha ;)!....

RESTful *Whatever

David Antonio Muñoz Gaete

Page 2: Rest whatever

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

Page 3: Rest whatever

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

Page 4: Rest whatever

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)

Page 5: Rest whatever

“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

Page 6: Rest whatever

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

Page 7: Rest whatever

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)

Page 8: Rest whatever

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.

Page 9: Rest whatever

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.

Page 10: Rest whatever

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.

Page 11: Rest whatever

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.

Page 12: Rest whatever

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

Page 13: Rest whatever

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

Page 14: Rest whatever

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)

Page 15: Rest whatever

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": ”[email protected]", ”name": ”David Antonio Muñoz Gaete” }, { "token": "30e517b6-5f76-4fd3-8668-fefae56c8519” ….......

Page 16: Rest whatever

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

Page 17: Rest whatever

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

Page 18: Rest whatever

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.

Page 19: Rest whatever

RESTFul

Diseño Rapidez

Conocimiento

OD

ATA

C#Emprendimiento

Microservicios

API

ProgramaciónGALE

Servicios

Fabric

Experiencia

Soluciones

Escalable

Calidad

Workshop Practico(metiendo manos…)

Page 20: Rest whatever

Instalación Demosmothership$: git clone https://github.com/dmunozgaete/demo-restful.git mothership$: cd Demosmothership$: npm installmothership$: bower installmothership$: grunt lift

Page 21: Rest whatever

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