APIs REST #devfestBilbao
•
1 j'aime•1,329 vues
Este documento describe los principios fundamentales de REST y las mejores prácticas para diseñar APIs HTTP. Explica los tres niveles de madurez REST (URI, HTTP, hipermedia), los métodos HTTP, códigos de estado, formatos de contenido, autenticación, versionado, errores y documentación de APIs. También cubre temas como hipermedia, formatos como HAL, operaciones asíncronas, disponibilidad de formatos, etiquetas HTTP y servicios backend como servicio.
Recommandé
Contenu connexe
En vedette
Similaire à APIs REST #devfestBilbao
Similaire à APIs REST #devfestBilbao (20)
Plus de Asier Marqués
Plus de Asier Marqués (20)
APIs REST #devfestBilbao
- 3. HTTP
- 4. HTTP - RFC 2616 Request Response
- 5. Request GET /usuarios Accept: text/html, application/json
- 6. Response GET /usuarios Status Code: 200 Content Type: application/json
- 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. RESTFul
- 10. Richardson Madurity Model Nivel 1 – Uso correcto de las URIs Nivel 2 – Uso correcto de HTTP Nivel 3 – Hypermedia
- 11. Nivel 1 - URIs
- 12. 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.
- 13. Recursos Un listado de usuarios → /usuarios Un usuario → /usuarios/{id}
- 14. Nombrar recursos Usamos nombres, no verbos Utilizamos una estructura jerárquica Evitamos añadir: Nombres de formatos Extensiones Filtros, órdenes paginaciones
- 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. Incorrecto Perfil de usuario → /getUser/{id} Edición de usuario → /users/{id}/edit Paginación de listado → /users/page/{page} Relaciones → /invoices/user/{id}
- 17. Correcto Perfil de usuario → /users/{id} Edición de usuario → /users/{id} Paginación de listado → /users?page={page} Relaciones → /user/{id}/invoices
- 18. Contenidos parciales, filtrados parciales GET /usuario/{id}?campos=id,nombre,email Status Code: 206
- 19. Formatos Incorrecto GET /user/{id}.xml Accept: text/html Correcto GET /user/{id} Accept: application/xml
- 20. Nivel 2 - HTTP
- 21. Métodos HTTP Leer Crear Editar Editar parcialmente Eliminar Opciones disponibles → → → → → → GET POST PUT PATCH DELETE OPTIONS
- 22. 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
- 23. Tipo de contenido, media types HTTP Request GET /recurso Accept: application/json Response GET /recurso Status Code 200 Content Type: application/json
- 24. Nivel 3 - Hypermedia
- 26. HATEOAS Hypermedia as the Engine of Application State RSDL REST Service Description Language
- 27. 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>
- 28. 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
- 29. GET /pedido/{id} Request Accept: application/vnd.acme+xml, application/xml Response Content Type: application/vnd.acme+xml
- 30. HAL - Hypertext Application Language application/hal+json http://stateless.co/hal_specification.html https://github.com/mikekelly/hal-browser
- 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": "rs:follow”: { "href": "/users/john/posts“ }, { "href": "/users/john“ }
- 32. 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“ }
- 33. Más cosas
- 34. Versiones En la URI /api/v1/recurso En el content-type application/vnd.acme+json;v=1 application/vnd.acme-1+json
- 35. Seguridad Autenticación HTTP: Basic, Digest Sistema propio basado en tokens OAuth Gateways: Layer7, apigee enterprise, 3scale... + HTTPs (no es opcional)
- 36. Operaciones asíncronas Callback URLs Notificaciones PUSH Inbound email parsing
- 37. 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
- 38. 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”
- 39. 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” }] }
- 40. Utilizando OPTIONS Request OPTIONS /users Response 200 Allow: GET, POST Content: { "POST": { "description": “Creamos un usuario", "parameters": {} }, “GET”: { "description": “Recuperamos el listado de usuarios“ } }
- 41. BaaS Backend as a service
- 42. 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.