API frente a servicio web: una breve historia de la API
Tengo más de 20 años de experiencia en desarrollo y arquitectura de software.
Las preguntas más confusas que suelo recibir son: ¿Qué es una API y qué es un servicio web? ¿Cuáles son las diferencias? ¿Son realmente diferentes? ¿Por qué los servicios web REST se denominan API?
En la próxima publicación, lo guiaré en un breve recorrido por la historia de la API para responder estas preguntas, pero primero debemos entender qué significa la API.
¿Qué es una API?
API significa Interfaz de programación de aplicaciones y, como sugiere el nombre, es una interfaz que permite que una pieza de código interactúe mediante programación con otra pieza de código. El fragmento de código puede ser una biblioteca, un recurso, un componente o incluso un sistema o aplicación diferente.
Las interfaces de programación de aplicaciones (API) pueden ser una API interna que permite interacciones naturales entre diferentes partes de la misma base de código de aplicación, como llamar a otra clase o biblioteca dentro de la misma implementación. Por otro lado, la API externa permite interacciones remotas, como llamar a otro componente para la misma aplicación ubicado en un entorno diferente (para aplicaciones distribuidas) o incluso llamar a una aplicación completamente diferente. Las interacciones externas requieren una comunicación de red compatible con un protocolo de red (como HTTP, JMS, TCP, etc.).
Si la API (interna o externa) se diseña cuidadosamente, puede aumentar la reutilización de la solución, ocultar la complejidad de la implementación y reducir la dependencia del cliente de la implementación interna, lo que debería mejorar el soporte general de la solución.
En el siguiente diagrama, una interfaz llamada «SortI» es un ejemplo de su propia API interna que permite que el código del cliente realice la función de clasificación sin conectarse directamente a la conversión principal.
En el diagrama anterior, si decidimos cambiar la implementación de BubbleSort con HeapSort, el cliente no se verá afectado, dado que la interfaz no se ha cambiado.
Componentes básicos de la API
La API consta de tres componentes principales:
Desplácese hasta Continuar
- Actividades: Este es el conjunto de acciones y operaciones proporcionadas por la interfaz. Por ejemplo, los métodos definidos en la interfaz java o las operaciones definidas en el archivo WSDL
- fecha modelo: La estructura de datos para operaciones de entrada o salida. Por ejemplo, los parámetros de entrada y la estructura de retorno para las operaciones de la interfaz Java o los esquemas WSDL de los mensajes de entrada y salida.
- Formato de fecha: Este es el formato que determina el formato de los datos. Por ejemplo, un formato binario para API internas y un formato SOAP para WS basado en SOAP.
historial de API
La historia de la API se puede dividir en cuatro generaciones principales, como se ilustra en el siguiente gráfico:
De acuerdo con el diagrama anterior, la API de tercera generación era una API web que tenía dos estilos principales: WS basado en REST WS y WS basado en SOAP, donde las llamadas API remotas se realizaban a través de Internet utilizando principalmente el protocolo HTTP.
En el siguiente diagrama, profundizaremos en la historia de la generación web para ver cómo ha evolucionado la API web con el tiempo.
la pregunta correcta
Ahora está claro que la pregunta correcta debería ser: ¿Cuál es la conexión entre el servicio web y la API? Y como hemos visto, el servicio web es solo un tipo de API.
Hasta ahora, es posible que se pregunte por qué los servicios web REST se denominan API. La razón más probable fue el odio a los servicios web SOAP por parte de los adaptadores REST, quienes decidieron darle a este estilo un nuevo nombre que no tiene «servicios web» y aparentemente tampoco «SOAP» y finalmente decidió llamarlo «API REST». Con el tiempo se ha convertido en una simple ‘API’ por sencillez, lo que ha causado mucha confusión, ya que era difícil saber si hablábamos de la API en general o del REST WS en particular.
En consecuencia, como consejo general, asegúrese de que cuando tenga una discusión sobre API, el oyente sepa de qué tipo de API está hablando.
Este contenido es preciso y verdadero al leal saber y entender del autor y no pretende reemplazar el asesoramiento formal e individualizado de un profesional calificado.
© 2022 Haitham Raik