Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2

Share

Download to read offline

Define y desarrolla tu primera api

Download to read offline

Meetup sobre cómo definir una API

Related Books

Free with a 30 day trial from Scribd

See all

Define y desarrolla tu primera api

  1. 1. Define y desarrolla tu primera API Marco Antonio Sanz
  2. 2. ¿Quienes somos? Grupo de meetup http://www.meetup.com/API-Addicts/ Meetups realizados ❏ MADA. Metodología ágil de definición de APIs ❏ Taller: Definición de APIs ❏ Taller: Desarrolla tu primera API ❏ Seguridad en las APIs ❏ El Mundo Big Data y las APis ❏ El Mundo Cloud y las APis ❏ Apis como modelo de negocio ❏ Define y desarrolla tu primera API Marco Antonio Sanz:http://es.linkedin.com/pub/marco-antonio-sanz-molina-prados/18/335/97/
  3. 3. Patrocinadores ¿qué nos ofrece? ➢ know - how de apis ➢ Experiencia en el gobierno de Apis ➢ Ejemplos de arquitecturas ➢ Experiencia en el mundo Cloud Calle Velasco 13 Tlf: 658 89 75 75 admin@cloudappi.net · www.cloudappi.net
  4. 4. Al pensar en una API, hay que pensar en desarrollar productos. Es un traje para varios clientes, por lo que a todos no les puede quedar bien. Un backend se desarrolla pensando en tu cliente, es un traje hecho a medida. API Backend ¿Qué es una API?
  5. 5. 1) Realizar un documento funcional 2) Realizar el diseño de la API 3) Realizar una implementación fake 4) Implementar la API 5) Validar la API 6) Generar documentación para developers 7) Generar casos de prueba (códigos de ejemplo) 8) Generar los SDks Pasos Definición de Apis
  6. 6. Hay que tener en cuenta los siguientes aspectos: ➢ Protocolo API (SOAP vs REST) ➢ Seguridad de la API,métodos de autenticación y autorización. Pj: Basic, oauth1, aouth2… ➢ API Manager (wso2, apigee, genoa) vs ESB (Oracle Service Bus..) ➢ Formato de datos de entrada / salida (xml, json…) Consideraciones generales Definición de Apis
  7. 7. Utiliza el protocolo HTTP para realizar las peticiones. El estándar RESTFULL, define cómo se deben realizar las peticiones REST, cuales son los métodos HTTP que se deben utilizar y cómo deben estructurarse las uris para que sean user-friendly. Podemos basarnos en https://github.com/WhiteHouse/api-standards para definir nuestra API. Principios básicos: ➢ Una URL identifica un recurso. Por ejemplo, GET http://testapi.cloudsystems.es/users RestFul Definición de Apis
  8. 8. ➢ Uniformidad de interfaz. Los recursos se manipulan a través de las métodos HTTP (PUT, GET, POST AND DELETE). ○ POST crea el recurso ○ PUT permite modificarlo ○ DELETE lo elimina ○ GET permite consultarlo. ○ Adicionalmente, se han introducido nuevos métodos, como PATCH (actualización parcial de un recurso). Principios básicos Restful
  9. 9. ➢ Uniformidad de salida. Los códigos HTTP de salida: ○ 1xxx: Informacional ○ 2xx: Resultado satisfactorio ■ 200: OK ■ 201: Recurso creado ○ 3xx: Redirecciones ○ 4xx: Errores de cliente ■ 400: Parámetros incorrectos ■ 404: recurso no encontrado Principios básicos Restful
  10. 10. ➢ Mensajes autodescriptivos: Los recursos están desacoplados de la representación. ➢ Los mensajes se pueden devolver en varios formatos. Los mensajes se pueden obtener en una variedad de formatos como HTML, XML, json… Para indicar estos formatos, se puede utilizar las cabeceras Content-Type y Accept o bién indicarlo al final de la URI. Por ejemplo: GET testapi.cloudsystems.es/users.json ➢ Todas las peticiones son sin estado. Principios básicos Restful
  11. 11. Crear: POST http://apitest.cloudsystems.es/users Modificar: PUT http://apitest.cloudsystems.es/users/23 Eliminar: DELETE http://apitest.cloudsystems.es/users/23 Consultar: GET http://apitest.cloudsystems.es/users Consultar un usuario: GET http://apitest.cloudsystems.es/users/23 Segundo nivel GET http://apitest.cloudsystems.es/users/23/cars urls Restful
  12. 12. Crear un usuario request: POST http://apitest.cloudsystems.es/users body: {"name": "Marco", "firstname": "Polo", "lastname": "2", "address": { "street": "blab bla", "number": "2" }} response: Header:HTTP CODE: 201 Body: {"result": { "info": "user created" }, "data": { "id": "23"} } Ejemplo Restful
  13. 13. Obtener usuarios: Request: GET http://apitest.cloudsystems.es/users Response: Header: HTTP CODE: 200 Body: { "result": { "info": "OK"}, "data": { "users": [ { "name": "Marco","firstname": "Polo", "address": {"street": "blabbla"}}, { "name": "Prueba","firstname": "ww", "address": {"street": "blab bla" }}] } } } Ejemplo Restful
  14. 14. Actualizar un usuario Request: PUT http://apitest.cloudsystems.es/users/23 body: {lastname:”González”} Response: Header: HTTP CODE: 200 Body: { “result”: {“info”:”user updated”}, {“data”:””} } Ejemplo Restful
  15. 15. Eliminar un usuario Request: DELETE http://apitest.cloudsystems.es/users/23 Response: Header: 200 OK Body: { "result": { "info": "user deleted" }, "data": "" } Ejemplo Restful
  16. 16. ● Fields ● Paging ● Expand ● Method ● Orderby Parámetros Definición de Apis
  17. 17. ➢ Devuelve los atributos seleccionados Fields Parámetros request: GET /users?fields=name response: header: http code 200 body: Original: "data": [ {"user": { "name": "marco", “dni”:”123123123”, “age”:”12” “phones”:[“1222”,”222”] }}]} Response: "data": [ {"user": { "name": "marco" }}]}
  18. 18. ➢ Parámetro limit / offset: Se debe mostrar un offset y el número de elementos a devolver. request: GET /users?limit=100&offset=200 response: header: http code 200/206 body: Restful { "paging": { "total": 10, "num": 3, "page_size": 100, "next": "/users?limit=100&offset=300", "previous": "/users?limit=100&offset=100", "last": "/users?limit=100&offset=900", "first": "/users?limit=100&offset=0" }, "data": [ {"user": { "name": "marco"}} ] } Paginación
  19. 19. Restful request: POST /users?method=put body: body: {"user": { "name": "pepe" }} Response: header: 200 OK body: {"result": { "info": "user updated" }} ➢Algunos clientes de API pueden no soportar realizar las peticiones PUT, DELETE. PUT y DELETE
  20. 20. ➢ Permite devolver el segundo o tercer nivel de un json Expand Restful Por defecto request: GET /users response: header: 200 OK body: {"data": [ {"user": { "name": "marco" }} ]} request: GET /users?expand=address response: header: 200 OK body: {"data": [ {"user": { "name": "marco" “address”:{ “street”:”Calle velasco” } }} ]}
  21. 21. ➢ Permite indicar el orden de la lista a devolver Orderby Restful request: GET /users?sortby=name DESC response: header: 200 OK body: {"data": [ {"user": { "name": "marco"}} {"user": { "name": "laura"}} ]} ORIGINAL request: GET /users?orderby=name DESC response: header: 200 OK body: {"data": [ {"user": { "name": "laura"}} {"user": { "name": "marco"}} ]}
  22. 22. ➢ Cabecera Authentication - Oauth 1.0 / 2.0 - Basic - Hmac Seguridad Restful request: GET /users?expand=address header: Authentication Basic dXN1YXJpbzpwYXNzd29yZA== response: header: 200 OK body: {"data": [ {"user": { "name": "marco" ]} Base64 (usuario:password)
  23. 23. - Accept - Content-type Formatos de entrada/salida Restful request: GET /users?expand=address header: Content-Type: application/xml Accept: application/json response: header: 200 OK body: {"data": [ {"user": { "name": "marco" ]} Base64 (usuario:password)
  24. 24. Las Apis deben versionarse como cualquier producto software. No tiene por qué coincidir con la implementación y suele indicarse en la url. METHOD /<version>/<resource> Versionado Restful request: GET /1/users?expand=address header: Content-Type: application/xml Accept: application/json response: header: 200 OK body: {"data": [ {"user": { "name": "marco" ]}
  25. 25. RAML Api Designer
  26. 26. #%RAML 0.8 title: GitHub API version: v3 baseUri: https://api.github.com mediaType: application/json protocols: [ HTTP, HTTPS ] schemas: - User: schema/user.json Users: schema/users.json Org: schema/org.json Orgs: schema/orgs.json song** Parámetros generales de la API Existe una sección principal que describe información general de la API, como la siguiente: ❏ title: Título de la API ❏ version: versión de la API. ❏ baseUri: url dónde se va a desplegar la API. ❏ mediaType: Tipo de dato de que va a soportar la API ❏ protocols: Protocolos disponibles para la API (HTTP/HTTPS) ❏ schemas: permite importar schemas json para ser utilizados posteriormente Documento root RAML
  27. 27. ❏ parámetros globales: permiten definier parámetros comunes a varios servicios. ❏ queryParameters: Son los parámetros que van en la query. Son los que se pasan como get XXX/users?username=marco ❏ uriParameters: son los parámetros que van directamente en la URI. En RestFul sólo deberían ser identificadores de recursos. ❏ responses: Respuestas del servicio. Hay que especificar el formato de respuesta, y además, se puede añadir su schema y un ejemplo. Los schemas pueden ir en json schema o en xsd. /users: is: [ paged ] get: queryParameters: username: description: user to find 200: body application/json: example: | { "result": { "info": "user created" } Métodos GET RAML
  28. 28. ❏ body: Toda petición post debe ir acompañada con información de entrada. ❏ responses: Respuestas del servicio. Hay que especificar el formato de respuesta, y además, se puede añadir su schema y un ejemplo. Los schemas pueden ir en json schema o en xsd. post: description: creates an user body: application/json: example: | {"name": "Marco", "firstname": "Polo", "lastname": "2", "address": { "descripcion": "blab bla", "number": "2" }} responses: 200: body: application/json: example: | {"result": { "info": "user created" }, "data": { "id": "23" } } Métodos POST RAML
  29. 29. put: description: updates an user body: application/json: example: | {"name": "Marco", "firstname": "Polo", "lastname": "2", "address": { "descripcion": "blab bla", "number": "2" }} responses: 200: body: application/json: example: | {"result": {"info": "user updated"},"data": ""} ❏ uriParameters: Permite identificar un recurso ❏ queryParameters: Permite filtrar los recursos ❏ responses: Respuestas del servicio. Hay que especificar el formato de respuesta, y además, se puede añadir su schema y un ejemplo. Los schemas pueden ir en json schema o en xsd. ❏ body: Enviar los campos a modificar. Se debería utilizar el método HTTP PATCH para modificaciones parciales. Métodos PUT RAML
  30. 30. /{userId}: uriParameters: userId: description: user id delete: description: removes a user responses: 200: body: application/json: example: | { "result": { "info": "user deleted" }, "data": "" } ❏ uriParameters: Permite identificar un recurso ❏ queryParameters: Permite filtrar los recursos ❏ responses: Respuestas del servicio. Hay que especificar el formato de respuesta, y además, se puede añadir su schema y un ejemplo. Los schemas pueden ir en json schema o en xsd. Métodos DELETE RAML
  31. 31. Desarrollo de una implementación con las interfaces de entrada y salida. Implementado Fake RAML
  32. 32. Desarrollo de una implementación con las interfaces de entrada y salida. Implementado Fake RAML
  33. 33. ➢ Seguridad. API Managers ➢ Carga del sistema. ➢ Entorno (¿Desplegar en un PAAS o en un IAAS?) ➢ Estadísticas ➢ Logs del sistema Consideraciones generales Apis
  34. 34. Ruegos y preguntas
  35. 35. Contacta en: Email: admin@apiaddicts.org Web: http://www.meetup.com/APIAddicts Siguenos en: ➢ Linkedin: ApiAddicts ➢ Twitter: @apiaddicts ➢ Facebook: APIAddicts ➢ Meetup: APIAddicts Contacta
  • gblumen

    May. 24, 2018
  • nagga

    Jun. 7, 2016

Meetup sobre cómo definir una API

Views

Total views

796

On Slideshare

0

From embeds

0

Number of embeds

61

Actions

Downloads

29

Shares

0

Comments

0

Likes

2

×