Tipos de API según su función y tecnología
Para encontrar la forma más inteligente de gestionar la integración de aplicaciones empresariales, debe analizar qué hacen las organizaciones de TI más efectivas para gestionar los desafíos de la complejidad, la seguridad, la escalabilidad y la demanda de recursos de integración de las API.
También necesita mirar de cerca dentro de su propio proyecto para identificar las brechas del proceso. Encontrar los enfoques de mejores prácticas para la seguridad de las API y los mejores enfoques de práctica para la escalabilidad de las API se encuentran en la parte superior de las prioridades de TI de muchas organizaciones.
API de servicios web
Actualmente, muchas API se basan en estándares de servicios web residentes de hipertexto, como REST, SOAP, XML-RPC y JSON-RPC. Las API de servicios web se usan comúnmente en aplicaciones web y como parte de un enfoque de arquitectura orientada a servicios que a menudo prefieren las grandes empresas.
Los servicios web basados en el Protocolo simple de acceso a objetos (SOAP) se basan en un protocolo WC3. WC3 afirma que "SOAP es un protocolo liviano para el intercambio de información en un entorno descentralizado y distribuido". A menudo se asocia con el Lenguaje de descripción de servicios web (WSDL) y UDDI. WSDL se define como un lenguaje basado en XML para describir servicios web.
WSDL le permite saber qué debe esperar que haga el servicio web. WSDL es legible por máquina y legible por humanos, como SOAP y UDDI. La especificación "Universal Description, Discovery and Integration" (UDDI) es un medio para proporcionar un directorio de servicios web disponibles.
Los servicios web RESTful son cualquiera de un grupo de enfoques que se ajustan a los principios de la arquitectura de transferencia de estado representacional (REST).
Los principios de REST requieren una arquitectura de cliente / servidor sin estado generalmente basada en HTTP. Se ajustan al uso de los Indicadores de recursos universales (URI) y utilizan los métodos CRED de PUT, GET, POST y DELETE.
Los recursos están representados y, por lo tanto, están desacoplados de su origen. Los mensajes son autodescriptivos. Las interacciones con estado se logran a través de hipervínculos. Dado que todas las interacciones con los recursos son apátridas porque el mensaje que lo solicita es autónomo. La transferencia de estado explícita se usa para lograr interacciones con estado. Transfer XML o JSON se utilizan.
API de código fuente
Las API de código fuente ofrecen bibliotecas de objetos, clases, etc. Las API de código fuente a menudo se usan en proyectos de desarrollo para crear una aplicación compuesta. Las llamadas se realizan de acuerdo con los estándares del entorno de la aplicación, como J2EE o .NET.
API heredadas
Una variedad de enfoques heredados para interfaces de aplicaciones emplean archivos planos, protocolos de objetos remotos, interfaces de sistema operativo, API de hardware, protocolos de comunicación, colas de mensajes y otros medios. Hacer referencia a estos como legado no pretende ser peyorativo, sino una forma de agrupar una variedad de protocolos clásicos y establecidos, aunque algo más antiguos.
Un buen ejemplo de un tipo API heredado sería CORBA (COMMON Object Request Broker Architecture). Los tipos de objetos CORBA pueden ocurrir en muchos casos. Por lo tanto, aunque el tipo de objeto del cliente no cambia, cada instancia del tipo de objeto del cliente se asocia a través de un token a sus datos.
Tipos de API en el ciclo de desarrollo
API de Producción
Eventualmente, cada aplicación necesitará una API de producción. Este es el servidor que envía datos reales desde la base de datos, realiza actualizaciones e impone todos los permisos y la lógica comercial. No debe devolver datos a los usuarios que no deberían verlo, y no permite a los usuarios actualizar la información que no tienen permiso para cambiar. Las API de producción deben ser rápidas y escalables, ya que manejarán todo el tráfico del mundo real de la aplicación.
La mayoría de las aplicaciones ya tienen una API de producción, por lo que no es necesario entrar en más detalles sobre ellas.
API de desarrollo
Las API de desarrollo son las que tradicionalmente se han llamado "API falsas".
Las API de desarrollo son perfectas para trabajar con el cliente antes de que esté disponible la API de producción, lo que permite que continúe el progreso del front-end, aunque todavía no hay datos reales o bases de datos que lo respalden.
Las API de desarrollo generalmente no persisten datos en una base de datos y solo guardan todo en la memoria. A menudo es útil tener algunos datos de ejemplo que se cargan cuando se inicia el servidor.
Es difícil decir cuánta lógica debe tener una API de desarrollo, es decir, cuánto debe imitar la API de producción. Diferentes desarrolladores tienen diferentes gustos. Algunos prefieren una API mínima que no se preocupe por las validaciones de formularios, la integridad de los datos o la coherencia página por página.
Otros quieren una API que cree una ilusión más completa de tener un back-end real, uno que podrían usar para dar una demostración razonablemente precisa de la aplicación. Lo que funciona mejor depende de usted.
API simulada
Una API simulada funciona igual que los objetos falsos que puede haber utilizado al escribir pruebas unitarias: la prueba no depende de ninguna lógica.
En cambio, el código de prueba especifica cómo se llamarán los métodos del objeto simulado y, cuando se invocan, qué devuelven. Una API simulada funciona de la misma manera, lo que requiere que las pruebas indiquen qué puntos finales API se verán afectados, con qué datos y qué se devuelve.
Por último, una API simulada es un programa general que puede usar de proyecto a proyecto sin cambiarlo. Esa reutilización agrega consistencia entre proyectos, elimina la necesidad de dedicar tiempo al proyecto al escribir una API de prueba personalizada, y mantiene a los desarrolladores que ya saben que el protocolo de API simulado debe aprender otra herramienta específica del proyecto.
Fuzzing API
El último tipo de API es la API fuzzing. En lugar de comportarse de manera predecible, una API fuzzing hace lo inesperado. Devuelve datos aleatorios e inconsistentes y expone cómo se maneja el cliente.
¿Ignora los problemas y continúa? ¿Lanza un error? ¿Le da al usuario un mensaje significativo? ¿Deja registros para los desarrolladores? Las Fuzzing API hacen un trabajo mucho mejor que los humanos al encontrarse con casos problemáticos y probar suposiciones implícitas.
Las API alternativas son una herramienta importante para cada desarrollador en su caja de herramientas. Nos permiten hacer mucho más de lo que hace una API simple de producción, desde personalizar las respuestas hasta mejorar la forma en que se expresan las pruebas y ayudar a encontrar problemas que ni siquiera sabíamos buscar.