Por: Lenildo Morais, Maestro en la Ciencias de la Computación. Gerente de Proyectos en Ustore / Claro. También es profesor de la Universidad Federal Rural de Pernambuco.
(ITNOW)-. Las empresas confían cada vez más en las API para interactuar con sus clientes y socios. Todo comienza con saber qué tipo de API es la adecuada para usted. API es una forma poderosa y versátil de conectar aplicaciones y programas diversos y diversos.
Estas interfaces permiten que una amplia variedad de productos y componentes de software interactúen e intercambien datos. Con las API, los programadores también pueden agregar características y funcionalidades a los servicios que crean. Sin embargo, no todas las API son iguales. Los desarrolladores pueden trabajar con una variedad de tipos de API, protocolos y arquitecturas que satisfacen las necesidades únicas de diferentes aplicaciones y negocios.
Tipos de API web
Las interfaces de programación son ampliamente aceptadas y utilizadas en aplicaciones web. Hay cuatro tipos principales de API que se utilizan comúnmente en este contexto: públicas, asociadas, privadas y compuestas.
1) API Pública: Una API pública está abierta y disponible para que la use cualquier desarrollador o actor externo. Una empresa que cultiva una estrategia comercial que implica compartir sus aplicaciones y datos con otras empresas desarrollará y ofrecerá una API pública. Las API públicas generalmente asumen una autenticación y autorización moderadas. Una empresa también puede buscar monetizar la API imponiendo un costo por llamada para usar la API pública.
2) API de Socio: Una API de socio, disponible solo para desarrolladores externos o consumidores de API específicamente clasificados y autorizados, es una forma de facilitar las actividades de empresa a empresa. Por ejemplo, si una empresa desea compartir algunos de los datos de sus clientes con expertos en gestión de relaciones con los clientes (CRM), una API de socio puede conectar el sistema de datos interno del cliente a estos terceros. Sin embargo, no se permite ningún otro uso de la API. Los socios tienen derechos y licencias claros para acceder a estas interfaces. Por esta razón, las API de socios a menudo incorporan mecanismos de seguridad, autorización y autenticación más sólidos. Por lo general, los grupos no obtienen ingresos de estas API directamente: a los socios se les paga por sus servicios, no mediante el uso de API.
Ver más: DevOps en protección bancaria
3) API Internas: Una API interna (o privada) solo debe usarse dentro de la empresa para conectar sistemas y datos. Por ejemplo, una API interna puede conectar los sistemas de nómina y recursos humanos de una empresa. Las API integradas tradicionalmente exhiben una seguridad y autenticación débiles, si las hay, porque no están expuestas públicamente y estos niveles de seguridad se consideran dependientes de otras capas o políticas separadas.
Sin embargo, esto está cambiando a medida que la creciente conciencia de las amenazas y los requisitos de cumplimiento normativo influyen cada vez más en la estrategia de API de las organizaciones.
4) API Compuestas: Las API compuestas generalmente combinan dos o más interfaces de programación para establecer una secuencia de operaciones relacionadas o interdependientes. Las API compuestas pueden ser útiles para manejar comportamientos complejos o estrechamente relacionados y, a veces, pueden mejorar la velocidad y el rendimiento en comparación con las API individuales.
Arquitecturas y Protocolos de API
Las API intercambian comandos y datos, que requieren protocolos y arquitecturas, reglas, estructuras y restricciones claras. Actualmente existen tres amplias categorías de protocolos o arquitecturas API: REST, RPC y SOAP. Pueden describirse como “formatos”, cada uno con características e inconvenientes específicos. Se utilizan para diferentes propósitos.
1) REST: Quizás el enfoque más popular para la creación de API. REST se basa en una relación cliente-servidor que separa las partes frontal y posterior de la API y ofrece una flexibilidad considerable en el desarrollo y la implementación. REST es “estado sin”, lo que significa que la API en la tienda no tiene estado ni datos entre solicitudes. REST permite el almacenamiento en caché, que almacena las respuestas de la API en un tiempo lento o poco sensible. Las API REST, comúnmente denominadas “API RESTful”, también pueden comunicarse directamente u operar a través de sistemas intermedios como puertos de enlace API y balanceadores de carga.
2) RPC: El protocolo de llamada a procedimiento remoto (RPC) es una forma sencilla de enviar varios parámetros y recibir resultados. Las API de RPC invocan acciones o procesos ejecutables, mientras que las API de REST intercambian principalmente datos o recursos como documentos. El RPC se puede codificar en diferentes lenguajes, JSON y XML; estas API se denominan JSON-RPC y XML-RPC, respectivamente.
3) SOAP: Es un estándar de mensajería definido por el World Wide Web Consortium y utilizado para crear una API web, generalmente escrita en XML. SOAP admite una amplia variedad de protocolos de comunicación que se encuentran en Internet, como HTTP, SMTP y TCP. SOAP también es extensible e independiente del estilo, lo que permite a los desarrolladores diseñar API de SOAP de diferentes maneras y agregar fácilmente características y funcionalidades. El enfoque SOAP, a través del lenguaje de descripción de servicios web IDL (WSDL), determina cómo se procesa el mensaje, las funciones y los módulos incluidos, los protocolos de comunicación aceptados y los mensajes SOAP escritos.
A diferencia de REST, SOAP es un estándar muy estructurado, estrictamente controlado y claramente definido. Por ejemplo, los mensajes SOAP pueden contener hasta cuatro componentes, incluidos over, head, body y error (para el manejo de errores). REST no depende de un IDL, sino de varias especificaciones.
Comparación de Protocolo API
La elección de un formato de API puede tener un impacto profundo y duradero en el éxito y la adopción de una API. Las empresas deben seleccionar el formato más apropiado en función de la complejidad de la información que se intercambiará, el nivel de seguridad requerido en torno a esa información y la velocidad o rendimiento requerido para ese intercambio. Por ejemplo, un formato más simple puede ser más fácil de codificar y mantener, pero es posible que no proporcione el nivel de seguridad, como el cifrado, que requiere un usuario empresarial.
Los formatos más complejos pueden proporcionar esta seguridad, pero tienen curvas de aprendizaje más altas para los adoptantes o requieren más correcciones de errores y trabajo de desarrollador. La compensación rara vez es sencilla, pero existen consideraciones comunes a todos los principales formatos de API.
Veamos el ejemplo de REST y SOAP. Estas dos tecnologías están diseñadas para conectar aplicaciones y utilizan principalmente protocolos y comandos HTTP como GET, POST y DELETE. Ambos pueden usar XML para formular solicitudes y respuestas. Sin embargo, SOAP se basa en XML por diseño, mientras que REST también puede usar JSON, HTML y texto sin formato.
Cabe destacar además la gran diferencia entre estas dos tecnologías. SOAP es un protocolo de intercambio de datos XML, REST es un estilo de arquitectura. SOAP se crea a partir de llamadas a procedimientos remotos, mientras que REST se basa en recursos.
Por tanto, REST y SOAP intercambian información, pero de formas muy diferentes. SOAP se utiliza cuando una empresa requiere reglas claramente definidas para admitir intercambios de datos más complejos y la capacidad de invocar procedimientos. Como resultado, SOAP se considera más seguro ya que se basa en los protocolos WS-Security para configurar un sistema de cifrado y firma XML, así como tokens SAML. Debe proporcionar autenticación, integridad, confidencialidad y no repudio.
Las API de descanso admiten el protocolo TLS, que se actualiza con más regularidad, pero esto solo protege la capa de red.
Los desarrolladores suelen utilizar SOAP para API internas o de socios. No obstante, SOAP es un protocolo que no se ha actualizado desde 2007: los servicios que dependen de él suelen ser sistemas heredados. REST se utiliza para intercambios de datos relativamente simples y rápidos. REST también puede permitir una mayor escalabilidad, admitiendo grandes bases de usuarios activos.
Estas características hacen que REST sea popular para las API públicas, como las que se combinan con las aplicaciones móviles.RESTSOAPFunciona con XML, JSON, HTTP y textoFunciona con XML por defectoDirectrices basadas en una arquitectura fluida y flexibleReglas estrictas y claramente definidasNivel de seguridad modestoNivel de seguridad avanzadoManeja los datos correctamenteManeja correctamente los procesos (acciones)Utiliza poco ancho de banda es altamente escalableUtiliza más ancho de banda y es menos escalable
Es más fácil saber cuándo usar RPC. Al igual que SOAP, RPC está muy estructurado y está dirigido a API relativamente básicas capaces de invocar procesos. Entonces, la elección pasa a ser utilizar JSON o XML, y nuevamente, depende del propósito de la API, los tipos de información que se intercambiarán y el nivel de seguridad requerido.
JSON es el lenguaje más simple y los JSON-RPC solo admiten el intercambio de datos alfanuméricos (texto) con poca seguridad. XML-RPC procesa una amplia gama de datos, incluidos texto, imágenes, gráficos y diagramas, y más. Por lo tanto, XML ofrece capacidades superiores de manejo de documentos y mejores características de seguridad que JSON. Ambos enfoques admiten una variedad de lenguajes de programación, incluidos Python, Java y PHP.
En última instancia, las API basadas en RPC son una mala elección para el intercambio de datos debido a su soporte limitado para tipos de datos y su seguridad limitada. Sin embargo, pueden ser adecuados para algunas API compuestas integradas.
Por ejemplo, las API JSON-RPC pueden realizar llamadas sin esperar una respuesta y admiten múltiples llamadas simultáneas que se pueden procesar de forma asincrónica.
Comments