API escrita: rompió XML (dos)

La primera API de MyStore apareció hace 10 años. Todo este tiempo estamos trabajando en versiones existentes de la API y desarrollando nuevas. Y varias versiones de la API ya han sido enterradas.

Este artículo tendrá muchas cosas: cómo crear la API, por qué el servicio en la nube lo necesita, qué les da a los usuarios qué rastrillo conseguimos pisar y qué queremos hacer a continuación.

Mi nombre es Oleg Alekseev oalexeev , soy el director técnico y cofundador de MySklad.

¿Por qué hacer una API para un servicio?

Nuestros clientes, que son decenas de miles de empresarios, utilizan activamente soluciones en la nube: banca, tiendas en línea, contabilidad de productos, CRM. Conectado a uno, y ya es difícil de detener. Y ahora el quinto, octavo y décimo servicio facilita el trabajo del emprendedor, pero los usuarios transfieren datos entre estos servicios en la nube manualmente. El trabajo se convierte en una pesadilla.

La solución obvia es dar a los usuarios la capacidad de transferir datos entre servicios en la nube. Por ejemplo, importe y exporte datos como archivos, que luego pueden descargarse al servicio deseado. Los archivos generalmente se cambian al formato de cada servicio. Este es un trabajo manual más o menos simple, pero con el aumento en el número de estos servicios, se hace más difícil realizarlo.

Por lo tanto, el siguiente paso es la API. Con él, un servicio en la nube se beneficia al conectar múltiples servicios en un punto. La aparición de tal ecosistema atrae a nuevos clientes debido a oportunidades adicionales. Un producto con nueva funcionalidad se vuelve más rentable y útil.

Si crea sus propias interfaces de programa, atrae a vendedores de terceros en forma de programadores que conocen su producto gracias a la API. Comienzan a construir soluciones basadas en la API propuesta y ganan dinero automatizando las tareas de sus clientes.

El sistema de contabilidad de MyStore se basa en procesos simples. Lo principal es trabajar con documentos primarios, la capacidad de aceptar y enviar mercancías, y recibir informes comerciales sobre la base del primario. También hay transferencia de datos, por ejemplo, a la contabilidad en la nube, y su recepción desde los sistemas bancarios o puntos de venta. También trabajamos con tiendas en línea: recibimos información sobre productos y enviamos datos sobre saldos.

Primera API de MyStore

A lo largo de 10 años de trabajo de MyStore con la API, hemos adquirido todo tipo de integraciones que le permiten intercambiar datos, trabajar con bancos, pagar y usar telefonía externa.

En el primer año, permitimos cargar cualquier dato en formato XML. Entonces era mucho más comprensible y familiar para los usuarios mantener los datos fuera de línea, y no en algún tipo de nube allí, y les dimos esto. La descarga se inició mediante exportación manual desde la interfaz. Es decir, la API no se pudo llamar todavía.

Luego comenzamos a cooperar con Rusagro: ya usaban el ERP "adulto" para planificar la producción y las ventas, pero la carga de automóviles en las plantas estaba automatizada en MySklad. Entonces obtuvimos los primeros rudimentos de esta API: el intercambio entre nuestro servicio y ERP se realizó mediante el envío de un archivo grande con datos para todo tipo de documentos.

Esta es una buena opción para el intercambio de datos por lotes, pero junto con los documentos que tuvieron que transferir sus dependencias: información sobre bienes, contratistas y almacenes. Un vertedero de este tipo no es tan difícil de generar durante la exportación, pero es bastante difícil de desmontar durante la importación, ya que toda la información viene en un paquete: tanto sobre documentos nuevos como sobre documentos existentes.

La primera API XML no duró mucho: dos años después, comenzamos a reconstruirla. Incluso al comienzo de su trabajo, cometimos varios errores al construir la interfaz del software.


Cómo se hizo la API XML: una ilustración de uno de nuestros arquitectos. Por cierto, espera sus artículos.

Aquí están nuestros principales errores:

1. El marcado JAXB se realizó directamente en beans de entidad. Usamos Hibernate para comunicarnos con la base de datos, y el marcado JAXB se realizó en los mismos beans. Este error se produjo casi de inmediato: cualquier actualización de la estructura de datos llevó a la necesidad de notificar con urgencia a cualquiera que use la API, o de construir muletas que garanticen la compatibilidad con la estructura de datos anterior.
2. La API creció como una especie de adición, e inicialmente no determinamos qué parte del producto constituye. Ni siquiera pensamos si la API era algo importante, si era necesario mantener la compatibilidad con versiones anteriores para sus primeros clientes. En algún momento, el número de usuarios de API era aproximadamente el 5% del número pequeño total, y no se les prestó atención. El filtrado universal realizado a su debido tiempo nos ha llevado a ser utilizados como backend. Este filtrado no fue GraphQL en absoluto, sino algo así: funcionó a través de muchos parámetros de cadena de consulta. Con una herramienta tan poderosa, fue difícil para los usuarios resistirse, y las solicitudes nos fueron transferidas para que se enviaran directamente desde la interfaz de usuario de sus tiendas en línea. La situación fue una sorpresa desagradable, porque la prestación de dicho servicio debería requerir una carga diferente y una comprensión diferente de la API en sí misma como producto.
3. Debido al hecho de que la API no se desarrolló como un producto principal, la documentación de la API se produjo y publicó de acuerdo con el principio residual, mediante ingeniería inversa. Este camino parece bastante simple y conveniente, pero contrario al trabajo por contrato. Esto es cuando hay un cierto componente con un esquema de trabajo predefinido. El desarrollador lo implementa de acuerdo con este esquema y tarea, el componente se prueba, el cliente recibe un producto que coincide con la idea del analista. La ingeniería inversa, por otro lado, arroja un producto que simplemente existe: con muletas, soluciones extrañas y bicicletas en lugar de la funcionalidad necesaria.
4. El flujo completo de solicitudes que llegaron a través de la API no se pudo analizar más que un registro Nginx o un servidor de aplicaciones. Esto no nos permitió aislar áreas temáticas, excepto quizás dividirlas entre usuarios y suscriptores. Si no es posible regular el registro de la aplicación o los clientes, se hace imposible analizar la situación. Este problema ha tenido el menor impacto en el desarrollo de la API; se trata más de comprender su relevancia y funcionalidad.

Intento número dos: API REST

En 2010, intentamos construir un sistema de intercambio con contabilidad en línea: BukhSoft. No despegó. Pero en el proceso de integración, apareció una API completa: un servicio de intercambio REST, donde no había libertades como las llamadas a operaciones en forma de llamadas RPC. Toda la comunicación con la API se llevó a un modo estándar para descansar: la cadena de consulta contiene el nombre de la entidad, y la operación que se realiza con ella se establece utilizando el método http. Agregamos filtros al momento de actualizar las entidades, y los usuarios ahora tienen la oportunidad de crear replicación con sus sistemas.

En el mismo año, apareció una API para la descarga de saldos de almacén y productos. Las partes más valiosas del sistema estuvieron disponibles para los usuarios a través de la API: el intercambio de documentos primarios y datos estimados sobre los saldos y el costo de los bienes.

En diciembre de 2015, RetailCRM publicó la primera biblioteca de terceros en acceder a nuestra API. Comenzaron a usarlo de manera bastante activa, mientras que la popularidad del servicio en general creció, la carga en la API creció más rápido que la carga en la interfaz web. Una vez, el crecimiento se convirtió en un salto en la carga.





Y este salto, que se muestra con la flecha a la izquierda, llevó al asombro total del servidor que sirve a nuestra API. Durante una semana entendimos qué genera exactamente esta carga. Resultó que estas son las mismas solicitudes transmitidas a nuestra API desde los frentes de los clientes. Unos 50 clientes se lo comieron todo. Fue entonces cuando nos dimos cuenta de uno de nuestros errores: la ausencia total de límites.

Como resultado, introdujimos un límite en el número de solicitudes simultáneas. Desde una cuenta se hizo posible abrir simultáneamente no más de dos solicitudes. Esto es suficiente para trabajar en modo de replicación para intercambiar datos en modo por lotes. Y aquellos que querían usarnos como backend, desde ese momento se vieron obligados a cumplir más con las tarifas, ya que introdujeron el trabajo en varias cuentas en su software.

Ordenar

Desde 2014, la demanda de la API existente se ha convertido en una parte importante del negocio, y la propia API generó la mayor cantidad de datos en el intercambio de datos con los clientes. En 2015, lanzamos un proyecto para limpiar la API. Elegimos JSON en lugar de XML como formato y comenzamos a construirlo sobre la base de las características que se revelaron durante la implementación de la versión anterior:

1. Posibilidad de gestionar versiones. El control de versiones le permite desarrollar una nueva versión sin afectar una aplicación existente y sin interrumpir a los usuarios.
2. La capacidad del usuario para ver metadatos en la respuesta que recibe.
3. La capacidad de intercambiar documentos grandes. Si procesamos un documento con el número de posiciones de más de 4-5 mil, esto se convierte en un problema para el servidor: una transacción larga, una solicitud http larga. Creamos un mecanismo especial que le permite actualizar el documento en partes y administrar las posiciones individuales de este documento enviándolos al servidor.
4. Herramientas para la replicación: estaban en la versión anterior.
5. Los límites de carga son como el legado del rastrillo que se pisó en la versión anterior. Se introdujeron límites en el número de solicitudes en un período de tiempo, el número de solicitudes concurrentes y solicitudes de una dirección IP.

Desde ese momento, lanzamos dos versiones menores de la API y lanzamos varias API especializadas, pero en general el enfoque permaneció sin cambios. Un formato de intercambio actualizado y una nueva arquitectura han permitido corregir las deficiencias en la API mucho más rápido.

MyStore API hoy

Hoy MyStore API resuelve muchos problemas:

• intercambio de datos con tiendas en línea, sistemas de contabilidad, bancos;
• recibir datos de liquidación, informes;
• utilizar como back-end para aplicaciones cliente: nuestras aplicaciones móviles y la caja de escritorio funcionan a través de la API
• envío de notificaciones sobre cambios de datos en MyStore - webhooks;
• telefonía
• Sistemas de fidelización.

Basado en la API, nuestro CEO Askar Rakhimberdiev rhino en cuatro horas escribió un bot de telegramas que extrae el resto a través de la API: github.com/arahimberdiev/com-lognex-telegram-moysklad-stock

Ahora números secos.

Aquí están nuestras estadísticas para la antigua API REST:

• 400 empresas;
• 600 usuarios;
• 2 millones de solicitudes por día;
• 200 Gb / día de tráfico saliente.

Y esto es a lo que llegamos con toda la API de MyStore:

• más de 70 integraciones (algunas de ellas se pueden encontrar aquí www.moysklad.ru/integratsii );
• 8500 empresas;
• 12,000 usuarios;
• 46 millones de solicitudes por día;
• 2 Tb / día de tráfico saliente.

Que sigue

Los planes de desarrollo de API están en discusión activa. Intentamos tener en cuenta la experiencia operativa que los usuarios nos brindan. No siempre y no todo se hace de inmediato, pero no muy lejos está la nueva versión de la API con metadatos más convenientes y una estructura menos pesada, OAuth para autenticación, una API para aplicaciones integradas en la interfaz.

Puede seguir las noticias en un sitio especial para desarrolladores de integración con MySklad: dev.moysklad.ru .