APIs REST #devfestBilbao

1,056 views
914 views

Published on

Mi charla sobre APIs REST para el Dev Fest Bilbao.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,056
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

APIs REST #devfestBilbao

  1. 1. #REST Asier Marqués @asiermarques
  2. 2. linkedin.com/in/asier @asiermarques
  3. 3. HTTP
  4. 4. HTTP - RFC 2616 Request Response
  5. 5. Request GET /usuarios Accept: text/html, application/json
  6. 6. Response GET /usuarios Status Code: 200 Content Type: application/json
  7. 7. ¿Por qué hacer APIs HTTP? Evitar la dependencia del cliente con el backend. Utilizar un protocolo maduro, probado y muy usado. Mejorar la integración con servicios o aplicaciones de terceros.
  8. 8. RESTFul
  9. 9. Richardson Madurity Model Nivel 1 – Uso correcto de las URIs Nivel 2 – Uso correcto de HTTP Nivel 3 – Hypermedia
  10. 10. Nivel 1 - URIs
  11. 11. Recursos y URIs Cada información con la que queramos trabajar es un recurso. Usamos URLs, un tipo de URI que identifica y localiza un recurso.
  12. 12. Recursos Un listado de usuarios → /usuarios Un usuario → /usuarios/{id}
  13. 13. Nombrar recursos Usamos nombres, no verbos Utilizamos una estructura jerárquica Evitamos añadir: Nombres de formatos Extensiones Filtros, órdenes paginaciones
  14. 14. Incorrecto Perfil de usuario → /getUser/{id} Edición de usuario → /users/{id}/edit Paginación de listado → /users/page/{page} Relaciones → /invoices/user/{id}
  15. 15. Incorrecto Perfil de usuario → /getUser/{id} Edición de usuario → /users/{id}/edit Paginación de listado → /users/page/{page} Relaciones → /invoices/user/{id}
  16. 16. Correcto Perfil de usuario → /users/{id} Edición de usuario → /users/{id} Paginación de listado → /users?page={page} Relaciones → /user/{id}/invoices
  17. 17. Contenidos parciales, filtrados parciales GET /usuario/{id}?campos=id,nombre,email Status Code: 206
  18. 18. Formatos Incorrecto GET /user/{id}.xml Accept: text/html Correcto GET /user/{id} Accept: application/xml
  19. 19. Nivel 2 - HTTP
  20. 20. Métodos HTTP Leer Crear Editar Editar parcialmente Eliminar Opciones disponibles → → → → → → GET POST PUT PATCH DELETE OPTIONS
  21. 21. Códigos de estado HTTP No reinventar la rueda RFC 2616 – Sección 10 Información Éxito Redirección, proxy o caché Error de cliente Error de servidor → → → → → 1XX 2XX 3XX 4XX 5XX
  22. 22. Tipo de contenido, media types HTTP Request GET /recurso Accept: application/json Response GET /recurso Status Code 200 Content Type: application/json
  23. 23. Nivel 3 - Hypermedia
  24. 24. http://roy.gbiv.com/untangled/2008/rest-apis-must-behypertext-driven
  25. 25. HATEOAS Hypermedia as the Engine of Application State RSDL REST Service Description Language
  26. 26. GET pedido/{id} <pedido> <id>666</id> <estado>Procesado</estado> <links> <link rel=”factura”> http://api.acme.com/api/pedido/666/factura </link> <link rel=”pago”> http://api.acme.com/api/pedido/666/pago </link> </links> </pedido>
  27. 27. Hypermedia y HATEOAS Nos permite desacoplar al máximo el cliente del servidor. Nos da flexibilidad ante cambios futuros en nuestra API. Nos permite automatizar peticiones sin tener que conocer de antemano la API. Utilizamos media type propios. Accept: application/vnd.{tu servicio} +json
  28. 28. GET /pedido/{id} Request Accept: application/vnd.acme+xml, application/xml Response Content Type: application/vnd.acme+xml
  29. 29. HAL - Hypertext Application Language application/hal+json http://stateless.co/hal_specification.html https://github.com/mikekelly/hal-browser
  30. 30. GET /users/john { "username": "bio": "john", "Un tipo majísimo, siempre saluda en la escalera.", "real_name": "John Smith”, "_embedded": { "rs:addresses": [] }, "_links": { "self": { "href": "/users/john” }, "curies": [{ "name": "rs", "href": "http://api.acme.com/docs/rels/{rel}", "templated": true }], } } "rs:posts": "rs:follow”: { "href": "/users/john/posts“ }, { "href": "/users/john“ }
  31. 31. GET /users/john { "username": "bio": "john", "Un tipo majísimo, siempre saluda en la escalera.", "real_name": "John Smith”, "_embedded": { "rs:addresses": [] }, "_links": { "self": { "href": "/users/john” }, "curies": [{ "name": "rs", "href": "http://api.acme.com/docs/rels/{rel}", "templated": true }], } } "rs:posts": { "href": "/users/john/posts“ }, "rs:follow”: { "href": "/users/john“ }
  32. 32. Más cosas
  33. 33. Versiones En la URI /api/v1/recurso En el content-type application/vnd.acme+json;v=1 application/vnd.acme-1+json
  34. 34. Seguridad Autenticación HTTP: Basic, Digest Sistema propio basado en tokens OAuth Gateways: Layer7, apigee enterprise, 3scale... + HTTPs (no es opcional)
  35. 35. Operaciones asíncronas Callback URLs Notificaciones PUSH Inbound email parsing
  36. 36. Disponibilidad de formatos Request GET /recurso Accept: application/xml Response (formato disponible) GET /recurso Content Type: application/xml 200 Response (formato no disponible) GET /recurso 406 Not acceptable
  37. 37. Uso de Etiquetas HTTP Request Request PUT /recurso If-Match: “XXXX” PUT /recurso If-Match: “XXXX” Response Response PUT /recurso 200 Etag: “YYYY” PUT /recurso 412 Precondition Failed Etag: “YYYY”
  38. 38. Descripción de errores Request Request POST /users POST /users Response Response POST /users 201 Created POST /users 400 Conflict Content { “_errors”: [{ “email”: “email is in use” }] }
  39. 39. Utilizando OPTIONS Request OPTIONS /users Response 200 Allow: GET, POST Content: { "POST": { "description": “Creamos un usuario", "parameters": {} }, “GET”: { "description": “Recuperamos el listado de usuarios“ } }
  40. 40. BaaS Backend as a service
  41. 41. BAAS, Backend as a Service Disponemos de una API de servidor totalmente funcional en minutos. Sin problemáticas de infraestructura, administración de servidores.. Integración con servicios de terceros out of the box, en algunos casos. Personalización del código de la API mediante Javascript y Eventos.
  42. 42. Gracias @asiermarques

×