Header Ads Widget

Ticker

6/recent/ticker-posts

¿Tu API es la Cenicienta o la Princesa Heredera?

 

¿Es-tu-API-Cenicienta-o-Corona-precios-

¿Ha notado que su API a veces se siente un poco incomprendida, vista como una actividad secundaria o una solución puramente técnica?

Esto puede suceder porque pones tu API a hacer un trabajo servil sin una estrategia comercial real . También puede deberse a que la documentación de la API no es bonita, correcta o comprensible. O porque los mensajes de error y los puntos finales son "crípticos" de entender para el desarrollador.

Al desarrollar con la API de otra persona, pueden surgir muchos problemas de usabilidad . El objetivo de cualquier proveedor de API debería ser escuchar los comentarios y eliminar este tipo de problemas.

Libera nuestras API

Deje de mantener su API escondida barriendo el polvo de las esquinas y lavando ollas y sartenes.

¿Qué pasaría si se pusiera fin a la opresión de las malvadas hermanas " Flat Files " y " Custom Code " de su API ¿Qué pasaría si pudiéramos darle un carruaje de calabaza, pantuflas de vidrio y un vestido de fiesta increíble y hacerlo presentable para un público más amplio?

Cuando PlanMill presentó su API en 2009, fue una de las primeras aplicaciones comerciales en Finlandia en tener algún tipo de API. Aplicar API a un ERP ha sido un proceso interesante, pero ahora, 7 años después, tienen al menos una belleza prometedora en sus manos. Solo necesitan prepararlo para la fiesta.

Coloque sus archivos planos en un carro de calabaza

Considere que uno de sus clientes tiene un desafío de integración y solicita un archivo plano muy específico. ¿Cómo puede ofrecer esto sin una gran cantidad de código personalizado o una solución de integración pesada que convierta la base de datos en archivos? Una forma de sortear este obstáculo es anticipando esta necesidad y creando una solución dedicada a la comida para perros.

Para PlanMill, la primera versión de un carro de calabaza consiste en un punto final de integración / consumo de archivos planos , una interfaz de usuario de importación construida con React.js y una arquitectura de aplicación de una sola página que lo consume. Los archivos CSV consumidos por la API se transforman con una capa de transformación simple y configurable en archivos JSON llenos de llamadas API normales de recursos específicos.

Dado que el punto final de integración reutiliza los otros puntos finales de API, también aplica todas las comprobaciones y reglas comerciales a los datos importados, como si los datos se hubieran insertado a través de la interfaz de usuario o llamadas a la API directamente. Esto ayuda a evitar datos duplicados en el sistema y ayuda a los usuarios a usar un archivo plano en su sistema y obtener los datos actualizados o insertados con una sola carga, mientras que los datos del archivo se comparan con los datos que ya están en el sistema.

Anticipar una solución más personalizada para que los clientes consumieran a través de API era fundamental para el éxito de PlanMill en la optimización de las integraciones de socios. A continuación, se muestran algunos casos previos y posteriores a la API para explicar el impacto de la ingeniería que una solución similar puede tener en su modelo de negocio, recursos y clientes:

El cliente desea una sincronización simple entre la gestión de contratos de terceros y el ERP:

"¿Cuánto cuesta realizar una integración SFTP + CSV, donde podríamos querer transferir la información básica del cliente a nuestro nuevo sistema de gestión de contratos?"

Así como ha dado un presupuesto o posiblemente lo haya implementado, el cliente necesita algo más. Luego, otro cliente necesita algo un poco similar, pero, por supuesto, los formatos de datos son diferentes y las columnas deben estar en un orden un poco diferente. Ah, y también debe incluir 15 campos personalizados allí.

Pre-API: 100-2000 líneas de código y configuraciones personalizados no reutilizables, realizados por usted para extraer el archivo. Además, configurar, probar y monitorear el SFTP.

Post-API: todo, incluidos los campos personalizados y los metadatos de los valores de campo, sale de la API. Una capa de transformación genérica de datos y puede seleccionar los campos que necesita. Dependiendo de las herramientas y la solución genérica, de 100 a 500 líneas de código totalmente reutilizable, ya sea en su extremo, en un IaaS o en un sistema de terceros.

Asista a la conferencia API Stack en Helsinki

Un ejemplo un poco más complejo con un sistema ITSM (Gestión de servicios de TI) en las instalaciones:

“¿Cuánto cuesta integrar nuestro nuevo sistema ITSM a su sistema? Es una solución local con acceso limitado desde el exterior, somos un par de países al sur de usted y de hecho lo necesitamos ayer. ¿No podría simplemente preparar un buen CSV que pudiéramos usar para sincronizar prácticamente todos los datos centrales incontables veces al día en ambas direcciones? "

Pre-API: 5 días de desarrollo, probablemente la mitad en el sitio

Post-API: "Entregue esta documentación de API a su parte de integración, contáctenos si tiene preguntas"

Y los casos de importación agradables y "simples":

“Solo necesitamos que nuestros clientes potenciales se carguen en su sistema. Es simple; los obtenemos de las agencias de reserva de terceros cada semana. Oh, ¿qué aspecto tiene el archivo? Bueno, puede ser cualquier cosa, todos nos envían archivos de aspecto diferente desde sus propios sistemas. Y lo más importante es evitar la duplicación de clientes potenciales o la actualización de empresas existentes que ya están en el sistema. Oh, ¿necesitas una identificación única para manejar eso? Bueno, nuestros datos pueden tener una identificación comercial, un nombre de cuenta o al menos un nombre de dominio ".

O

“Una parte de nuestro negocio es SaaS, pero también vendemos servicios profesionales y demás. ¿Podemos de alguna manera importar los costos de transacción relacionados con SaaS de nuestros otros sistemas a su sistema mensualmente para que podamos facturarlos a nuestros clientes? Realmente nos gustaría que todo se manejara a través de un sistema ".

O

“Vendemos optimización de motores de búsqueda, redes sociales y otras campañas a nuestros clientes. Necesitamos transferir los costos de la campaña de medios a su sistema, para poder facturarlos a los clientes y monitorear nuestro propio desempeño y rentabilidad. Todos los proveedores tienen archivos y formatos de apariencia diferente, pero todos tienen un número de cuenta de campaña, que debe usarse para hacer coincidir el proyecto al que pertenece cada campaña ".

Pre-API: al menos 3-5 días de especificaciones, comparación de modelos de datos, pruebas, etc.

Post-API: “Aquí está nuestro caso de uso específico, pero aún documentación de importación genérica. Verifique eso y decida si desea realizar la importación cargando manualmente los archivos, o si desea integrarse con nuestra API "

Lea también: Cómo las API están evolucionando el panorama B2B

¿IaaS se adapta a los pies de su API como una zapatilla de vidrio?

Los nuevos príncipes en la ciudad que cortejan a su API son los proveedores de integración como servicio (IaaS), también llamados plataformas de integración (IPaaS), o incluso operadores específicos de áreas comerciales de alto nivel como Service Integration and Management (SIAM) co -ordinadores.

Puede encontrar los roles invertidos: tradicionalmente, era el príncipe probando la zapatilla de cristal a los pies de cientos de niñas. En API-land, será usted quien se pruebe las zapatillas proporcionadas por decenas de proveedores de integración a los puntos finales de sus API.

Durante este proceso de adaptación, es posible que algunos se adapten mejor a su API y a los propósitos de su cliente que otros. Los proveedores que puede considerar incluyen Zapier , IFTTT , Mulesoft , BizTalk o soluciones específicas del área comercial en Finlandia como Sofigate , Verco y las integraciones relacionadas con ITSM de Ambientia . Los aspectos importantes que debe considerar al elegir entre estos proveedores son:

El intercambio de datos debe hacerse con cuidado

Considere dónde se enrutan sus datos o posiblemente incluso se almacenan, según la plataforma de integración. Tenga mucho cuidado si manipula alguno de estos:

  • Secretos de la empresa : empresa interna y red inmediata;
  • Datos personales : integraciones de nómina, números de seguro social, licencias por enfermedad, números de cuentas bancarias y tarjetas de crédito, contraseñas;
  • Dinero real : Facturación electrónica, contabilidad, facturas, informes de gastos, sueldos, etc.

La Ley de Datos Personales y / o las Políticas de la Compañía controlan algunos de los datos que se pueden compartir. Por ejemplo, el número de la seguridad social finlandesa no debe almacenarse en sistemas accesibles fuera de la Unión Europea. Algunos datos también están controlados por tratados comerciales y gubernamentales .

Esto significa que si integra su API con algo como Zapier, y le proporciona acceso /users, es posible que deba omitir, cifrar o proteger específicamente los datos confidenciales, aunque el usuario pueda tener acceso para usar esos datos.

Consulte nuestra investigación sobre las leyes internacionales de privacidad de datos  para obtener más información sobre este tema.

Empujar o sondear

Cuando proporcione una API, debe considerar cómo se verá afectada su plataforma cuando miles (o millones) de usuarios soliciten nuevos datos cada 1 a 15 minutos. Por lo general, significa que están extrayendo todos los registros de usted y luego comparando con ellos mismos si hay algún dato nuevo o modificado que deban manejar.

El alto uso de grandes llamadas de datos consume recursos para ambos extremos. Es por eso que debería considerar seriamente la implementación de enlaces RESTful a su API. En lugar de que todos tomen las faldas de su API con solicitudes como "¿Tienes algo nuevo para mí? ¿Vos si? ¿Vos si?" su plataforma estaría a cargo y solo recibiría solicitudes de suscripción a los ganchos que proporciona.

Luego, su plataforma simplemente muestra un mensaje a los suscriptores que dice: "¡Tienen un nuevo proyecto!", "Su cuenta 123 se acaba de eliminar" o "Su pedido de venta 456 se acaba de actualizar".

Tenga mucho cuidado con el diseño del gancho, tanto por motivos de seguridad como de uso. Si tiene recursos de tamaño razonable, puede entregar todo el recurso como carga útil de la solicitud cuando se activa el enlace, de modo que el destinatario no tenga que realizar una solicitud real para obtener los datos. Es posible que el destinatario desee filtrar algunos casos; por ejemplo, si solo está interesado en cuentas con el tipo cliente, debería poder suscribirse solo a los activadores que desee o poder filtrar los datos en función del contenido recibido. Sin embargo, si proporciona el contenido completo del recurso cuando se activa el enlace, también debe implementar la autenticación en esa publicación, lo que hace que las cosas sean un poco más complicadas de lo que deberían ser.

Como ejemplo, para la API de PlanMill v1.5 se decidió ofrecer información mínima pero útil, principalmente la identificación del recurso y alguna información de filtrado que el cliente ha proporcionado al suscribirse al gancho. De esta manera, un cliente puede solicitar (mediante autenticación) más información sobre el recurso si lo necesita. Esto también resolvió un problema específico de manejo de procesos asincrónicos, que cambiaría los datos milisegundos después de la operación de guardado inicial. En un sistema ERP, estos a menudo son necesarios para la lógica de precios y consolidación, porque las operaciones de cálculo pesadas generalmente están involucradas al actualizar datos para facturación, planificación de proyectos, informes de tiempo y otros.

Ejemplo de una suscripción de gancho de la API de PlanMill:

 /hooks
   {
       id: 2836851,
       hook: "timereport.delete",
       url: "http://requestb.in/1cebrdl1",
       eventUser: 123,
       eventProject: 456
    }

Esto funciona muy bien con servicios como Zapier, Google Cloud Messaging y Apple y Microsoft's mensajería. Los ganchos son suscritos por el cliente y los ganchos se activan cuando ocurre un evento adecuado. Al diseñar sus ganchos REST, un buen recurso es el manifiesto "Stop That Polling Madness" de Zapier

Autenticación y documentación Viste nuestra API para la fiesta

La mayoría de las API desarrolladas en los primeros días de las API utilizaban una clave de API simple para la autenticación y XML y una versión de JSON como formato de datos de retorno.

A medida que las herramientas API y las bibliotecas se han desarrollado y la seguridad se ha convertido en una preocupación mayor, OAuth2 y OpenID Connect han ganado más soporte. La mayoría de herramientas como Postman , SOAPui , Zapier y otras ofrecen una experiencia plug-and-play.

Finalmente, debe considerar cómo documentar su API. Considere tanto el usuario desarrollador de su API como la facilidad con la que su propio equipo puede mantener la documentación. Por ejemplo, la API de PlanMill se documenta mediante RAML y se genera en HTML mediante Raml2Html. Existen otros métodos, como alojar la documentación en GitHub , que luego actúa como centro de desarrollo para problemas y preguntas relacionadas con la API.

¿Está su API lista para heredar el Reino?

Cuando sus usuarios comiencen a adoptar su API o cuando decida conectarla a una plataforma de integración, considere cuidadosamente cuáles son sus puntos finales y funcionalidades más interesantes. ¿Deberías ofrecer todo instantáneamente a través de tu API? Es más probable que sea mejor comenzar con lean con un par de puntos finales, ver cómo se usan en la naturaleza e implementar funciones o cambios adicionales solicitados por sus clientes, socios o desarrolladores de integración y de interfaz de usuario internos. Una mentalidad de desarrollo iterativo ayuda a disminuir las revisiones grandes, minimizando el tiempo y los recursos desperdiciados. También recibe resultados y comentarios más rápido.

Sin embargo, esté preparado: el costo inicial de "instalar API" en un sistema existente podría ser bastante elevado. Es posible que deba rediseñar partes clave de su sistema, como la autenticación, el acceso a sus objetos comerciales y los formatos de datos que ofrece. Al menos debe colocar una capa frente a su núcleo existente para ofrecer estos servicios de una manera compatible con API.

A riesgo de sonar demasiado femenino para el ingeniero de API promedio, considere el proceso de API-fing de su sistema existente como ponerse una capa de maquillaje (autenticación, JSON, formatos de datos, recursos) y una hermosa corona en su sistema: esto es lo que necesitará para hacer de su API una princesa heredera lista para heredar el reino.

Recuerde, Cenicienta no lo hizo todo sola. Tenía un hada madrina y amigos mágicos del bosque a su lado ... ¡asiste a la API Stack Conference el 12 de abril para conocer a otros y aprender de ellos para mejorar tu estrategia general de API!

Publicar un comentario

0 Comentarios