Una interfaz de programación de aplicaciones ( API ) es una forma para que dos o más programas o componentes de computadora se comuniquen entre sí. Es un tipo de interfaz de software que ofrece un servicio a otras piezas de software . [1] Un documento o estándar que describe cómo construir o utilizar dicha conexión o interfaz se denomina especificación API . Se dice que un sistema informático que cumple con este estándar implementa o expone una API. El término API puede referirse a la especificación o a la implementación. Mientras que la interfaz de usuario de un sistema dicta cómo sus usuarios finales interactúan con el sistema en cuestión, su API dicta cómo escribir código que aproveche las capacidades de ese sistema.
A diferencia de una interfaz de usuario , que conecta una computadora con una persona, una interfaz de programación de aplicaciones conecta computadoras o piezas de software entre sí. No está destinado a ser utilizado directamente por una persona (el usuario final ) que no sea un programador informático que lo incorpore al software. Una API suele estar formada por diferentes partes que actúan como herramientas o servicios disponibles para el programador. Se dice que un programa o programador que utiliza una de estas partes llama a esa parte de la API. Las llamadas que componen la API también se conocen como subrutinas , métodos, solicitudes o puntos finales . Una especificación API define estas llamadas, lo que significa que explica cómo usarlas o implementarlas.
Uno de los propósitos de las API es ocultar los detalles internos de cómo funciona un sistema, exponiendo solo aquellas partes que un programador encontrará útiles y manteniéndolas consistentes incluso si los detalles internos cambian más adelante. Una API puede diseñarse a medida para un par particular de sistemas o puede ser un estándar compartido que permite la interoperabilidad entre muchos sistemas.
Existen API para lenguajes de programación , bibliotecas de software , sistemas operativos de computadora y hardware de computadora . Los API se originaron en la década de 1940, aunque el término no surgió hasta las décadas de 1960 y 1970. El uso contemporáneo del término API a menudo se refiere a las API web , [2] que permiten la comunicación entre computadoras conectadas a través de Internet . Los desarrollos recientes en las API han llevado al aumento de la popularidad de los microservicios , que son servicios poco acoplados a los que se accede a través de API públicas. [3]
Al crear aplicaciones, una API simplifica la programación al abstraer la implementación subyacente y exponer solo los objetos o acciones que el desarrollador necesita. Mientras que una interfaz gráfica para un cliente de correo electrónico podría proporcionar al usuario un botón que realiza todos los pasos para buscar y resaltar nuevos correos electrónicos, una API para la entrada/salida de archivos podría brindarle al desarrollador una función que copie un archivo de una ubicación a otra sin requiriendo que el desarrollador comprenda las operaciones del sistema de archivos que ocurren detrás de escena. [4]
El término API inicialmente describía una interfaz solo para programas orientados al usuario final, conocidos como programas de aplicación . Este origen todavía se refleja en el nombre "interfaz de programación de aplicaciones". Hoy en día, el término es más amplio, incluyendo también software de utilidad e incluso interfaces de hardware . [6]
La idea de API es mucho más antigua que el término en sí. Los científicos informáticos británicos Maurice Wilkes y David Wheeler trabajaron en una biblioteca de software modular en la década de 1940 para EDSAC , una de las primeras computadoras. Las subrutinas de esta biblioteca se almacenaban en cintas de papel perforadas organizadas en un archivador . Este gabinete también contenía lo que Wilkes y Wheeler llamaron un "catálogo de biblioteca" de notas sobre cada subrutina y cómo incorporarla a un programa. Hoy en día, dicho catálogo se llamaría API (o especificación API o documentación API) porque instruye al programador sobre cómo usar (o "llamar") cada subrutina que el programador necesita. [6]
El libro de Wilkes y Wheeler de 1951, La preparación de programas para una computadora digital electrónica, contiene la primera especificación API publicada. Joshua Bloch considera que Wilkes y Wheeler "inventaron de forma latente" la API porque es más un concepto que se descubre que se inventa. [6]
El término "interfaz de programa de aplicación" (sin el sufijo ‑ing ) se registró por primera vez en un artículo llamado Estructuras de datos y técnicas para gráficos por computadora remotos presentado en una conferencia de AFIPS en 1968. [8] [6] Los autores de este artículo utilizan el Término para describir la interacción de una aplicación (un programa de gráficos en este caso) con el resto del sistema informático. Una interfaz de aplicación consistente (que consta de llamadas a subrutinas de Fortran ) tenía como objetivo liberar al programador de tener que lidiar con las idiosincrasias del dispositivo de visualización de gráficos y proporcionar independencia del hardware si se reemplazaba la computadora o la pantalla. [7]
El término fue introducido en el campo de las bases de datos por CJ Date [9] en un artículo de 1974 llamado The Relational and Network Approaches: Comparison of the Application Programming Interface . [10] Una API pasó a formar parte del marco ANSI/SPARC para sistemas de gestión de bases de datos . Este marco trataba la interfaz de programación de aplicaciones por separado de otras interfaces, como la interfaz de consulta. Los profesionales de bases de datos de la década de 1970 observaron que estas diferentes interfaces podían combinarse; una interfaz de aplicación suficientemente rica podría soportar también las otras interfaces. [5]
Esta observación condujo a API que admitían todo tipo de programación, no solo la programación de aplicaciones.
En 1990, el tecnólogo Carl Malamud definió la API simplemente como "un conjunto de servicios disponibles para un programador para realizar determinadas tareas" . [11]
La idea de API se amplió nuevamente con el surgimiento de las llamadas a procedimientos remotos y las API web . A medida que las redes de computadoras se volvieron comunes en las décadas de 1970 y 1980, los programadores quisieron llamar a bibliotecas ubicadas no sólo en sus computadoras locales sino también en computadoras ubicadas en otros lugares. Estas llamadas a procedimientos remotos estaban bien soportadas, en particular, por el lenguaje Java . En la década de 1990, con la expansión de Internet , estándares como CORBA , COM y DCOM compitieron para convertirse en la forma más común de exponer servicios API. [12]
La disertación de Roy Fielding , Estilos arquitectónicos y diseño de arquitecturas de software basadas en red en UC Irvine en 2000, describió la transferencia de estado representacional (REST) y describió la idea de una "interfaz de programación de aplicaciones basada en red" que Fielding contrastaba con la tradicional "biblioteca". API "basadas". [13] Las API web XML y JSON tuvieron una adopción comercial generalizada a partir de 2000 y continuaron a partir de 2022. API web es ahora el significado más común del término API. [2]
La Web Semántica propuesta por Tim Berners-Lee en 2001 incluía "API semánticas" que reformulan la API como una interfaz de datos abierta y distribuida en lugar de una interfaz de comportamiento de software. [14] Las interfaces y agentes propietarios se generalizaron más que los abiertos, pero la idea de la API como interfaz de datos se afianzó. Debido a que las API web se utilizan ampliamente para intercambiar datos de todo tipo en línea, API se ha convertido en un término amplio que describe gran parte de la comunicación en Internet. [12] Cuando se utiliza de esta manera, el término API tiene un significado superpuesto con el término protocolo de comunicación .
La interfaz de una biblioteca de software es un tipo de API. La API describe y prescribe el "comportamiento esperado" (una especificación), mientras que la biblioteca es una "implementación real" de este conjunto de reglas.
Una única API puede tener múltiples implementaciones (o ninguna, al ser abstracta) en forma de diferentes bibliotecas que comparten la misma interfaz de programación.
La separación de la API de su implementación puede permitir que los programas escritos en un idioma utilicen una biblioteca escrita en otro. Por ejemplo, debido a que Scala y Java se compilan en códigos de bytes compatibles , los desarrolladores de Scala pueden aprovechar cualquier API de Java. [15]
El uso de API puede variar según el tipo de lenguaje de programación involucrado. Una API para un lenguaje procedimental como Lua podría consistir principalmente en rutinas básicas para ejecutar código, manipular datos o manejar errores mientras que una API para un lenguaje orientado a objetos , como Java, proporcionaría una especificación de clases y sus métodos de clase . [16] [17] La ley de Hyrum [18] establece que "Con un número suficiente de usuarios de una API, no importa lo que prometas en el contrato: alguien dependerá de todos los comportamientos observables de tu sistema". Mientras tanto, varios estudios muestran que la mayoría de las aplicaciones que utilizan una API tienden a utilizar una pequeña parte de la API. [19]
Los enlaces de idiomas también son API. Al asignar las características y capacidades de un idioma a una interfaz implementada en otro idioma, un enlace de idioma permite que una biblioteca o servicio escrito en un idioma se utilice cuando se desarrolla en otro idioma. [ cita necesaria ]
Herramientas como SWIG y F2PY, un generador de interfaces de Fortran a Python , facilitan la creación de dichas interfaces. [20]
Una API también puede estar relacionada con un marco de software : un marco puede basarse en varias bibliotecas que implementan varias API, pero a diferencia del uso normal de una API, el acceso al comportamiento integrado en el marco está mediado por la ampliación de su contenido con nuevas clases. conectado al propio marco.
Además, el flujo de control general del programa puede estar fuera del control de quien llama y estar en manos del marco mediante inversión de control o un mecanismo similar. [21] [22]
Una API puede especificar la interfaz entre una aplicación y el sistema operativo . [23] POSIX , por ejemplo, proporciona un conjunto de especificaciones API comunes cuyo objetivo es permitir que una aplicación escrita para un sistema operativo compatible con POSIX se compile para otro sistema operativo compatible con POSIX.
Linux y Berkeley Software Distribution son ejemplos de sistemas operativos que implementan las API POSIX. [24]
Microsoft ha mostrado un fuerte compromiso con una API compatible con versiones anteriores, particularmente dentro de su biblioteca API de Windows (Win32), por lo que las aplicaciones más antiguas pueden ejecutarse en versiones más nuevas de Windows usando una configuración ejecutable específica llamada "Modo de compatibilidad". [25]
Una API se diferencia de una interfaz binaria de aplicación (ABI) en que una API se basa en código fuente, mientras que una ABI se basa en binario . Por ejemplo, POSIX proporciona API, mientras que Linux Standard Base proporciona una ABI. [26] [27]
Las API remotas permiten a los desarrolladores manipular recursos remotos a través de protocolos , estándares específicos de comunicación que permiten que diferentes tecnologías trabajen juntas, independientemente del idioma o plataforma. Por ejemplo, la API de conectividad de bases de datos de Java permite a los desarrolladores consultar muchos tipos diferentes de bases de datos con el mismo conjunto de funciones, mientras que la API de invocación de métodos remotos de Java utiliza el protocolo de métodos remotos de Java para permitir la invocación de funciones que operan de forma remota pero que parecen locales para el usuario. desarrollador. [28] [29]
Por lo tanto, las API remotas son útiles para mantener la abstracción de objetos en la programación orientada a objetos ; una llamada a un método , ejecutada localmente en un objeto proxy , invoca el método correspondiente en el objeto remoto, utilizando el protocolo de comunicación remota, y adquiere el resultado para usarlo localmente como valor de retorno.
Una modificación del objeto proxy también dará como resultado una modificación correspondiente del objeto remoto. [30]
Las API web son un servicio al que se accede desde dispositivos cliente (teléfonos móviles, computadoras portátiles, etc.) a un servidor web mediante el Protocolo de transferencia de hipertexto (HTTP). Los dispositivos cliente envían una solicitud en forma de solicitud HTTP y reciben un mensaje de respuesta generalmente en formato de notación de objetos JavaScript ( JSON ) o lenguaje de marcado extensible ( XML ). Los desarrolladores suelen utilizar API web para consultar un servidor en busca de un conjunto específico de datos de ese servidor.
Un ejemplo podría ser la API de una empresa de envío que se puede agregar a un sitio web centrado en el comercio electrónico para facilitar el pedido de servicios de envío e incluir automáticamente las tarifas de envío actuales, sin que el desarrollador del sitio tenga que ingresar la tabla de tarifas del remitente en una base de datos web. Si bien históricamente "API web" ha sido prácticamente sinónimo de servicio web , la tendencia reciente (la llamada Web 2.0 ) se ha alejado de los servicios web basados en el Protocolo simple de acceso a objetos ( SOAP ) y la arquitectura orientada a servicios (SOA) hacia servicios más directos. Recursos web de estilo de transferencia de estado representacional (REST) y arquitectura orientada a recursos (ROA). [31] Parte de esta tendencia está relacionada con el movimiento de la Web Semántica hacia el Marco de Descripción de Recursos (RDF), un concepto para promover tecnologías de ingeniería de ontología basadas en la web . Las API web permiten la combinación de múltiples API en nuevas aplicaciones conocidas como mashups . [32]
En el espacio de las redes sociales, las API web han permitido a las comunidades web facilitar el intercambio de contenido y datos entre comunidades y aplicaciones. De esta manera, el contenido que se crea dinámicamente en un lugar se puede publicar y actualizar en múltiples ubicaciones de la web. [33] Por ejemplo, la API REST de Twitter permite a los desarrolladores acceder a datos básicos de Twitter y la API de búsqueda proporciona métodos para que los desarrolladores interactúen con la búsqueda de Twitter y los datos de tendencias. [34]
El diseño de una API tiene un impacto significativo en su uso. [4] En primer lugar, el diseño de interfaces de programación representa una parte importante de la arquitectura del software , la organización de una pieza compleja de software. [35] El principio de ocultación de información describe el papel de las interfaces de programación como permitir la programación modular al ocultar los detalles de implementación de los módulos para que los usuarios de los módulos no necesiten comprender las complejidades dentro de los módulos. [36] Aparte del principio subyacente anterior, otras métricas para medir la usabilidad de una API pueden incluir propiedades como eficiencia funcional, corrección general y capacidad de aprendizaje para principiantes. [37] Una forma sencilla y comúnmente adoptada de diseñar API es seguir las pautas de evaluación heurística de Nielsen . El patrón del método Factory también es típico en el diseño de API debido a su naturaleza reutilizable. [38] Por lo tanto, el diseño de una API intenta proporcionar solo las herramientas que un usuario esperaría. [4]
Una interfaz de programación de aplicaciones puede ser síncrona o asíncrona . Una llamada API sincrónica es un patrón de diseño en el que el sitio de la llamada se bloquea mientras se espera que finalice el código llamado. [39] Sin embargo, con una llamada API asincrónica, el sitio de la llamada no se bloquea mientras se espera que finalice el código llamado y, en cambio, se notifica al hilo de llamada cuando llega la respuesta.
La seguridad de la API es muy crítica cuando se desarrolla una API pública. Las amenazas comunes incluyen inyección SQL , ataque de denegación de servicio (DoS), autenticación rota y exposición de datos confidenciales. [40] Sin garantizar prácticas de seguridad adecuadas, los malos actores pueden obtener acceso a información que no deberían tener o incluso obtener privilegios para realizar cambios en su servidor. Algunas prácticas de seguridad comunes incluyen una seguridad de conexión adecuada mediante HTTPS , seguridad de contenido para mitigar los ataques de inyección de datos y requerir una clave API para usar su servicio. [41] Muchos servicios API públicos requieren que usted utilice una clave API asignada y se negarán a proporcionar datos sin enviar la clave con su solicitud. [42]
Las API son una de las formas más comunes de integración de las empresas de tecnología. Aquellos que proporcionan y utilizan API se consideran miembros de un ecosistema empresarial. [43]
Las principales políticas para lanzar una API son: [44]
Un factor importante cuando una API se vuelve pública es la "estabilidad de la interfaz". Los cambios en la API (por ejemplo, agregar nuevos parámetros a una llamada de función) podrían romper la compatibilidad con los clientes que dependen de esa API. [48]
Cuando partes de una API presentada públicamente están sujetas a cambios y, por lo tanto, no son estables, dichas partes de una API en particular deben documentarse explícitamente como "inestables". Por ejemplo, en la biblioteca Google Guava , las partes que se consideran inestables y que podrían cambiar pronto están marcadas con la anotación Java @Beta . [49]
En ocasiones, una API pública puede declarar partes de sí misma como obsoletas o rescindidas. Esto generalmente significa que parte de la API debe considerarse candidata para ser eliminada o modificada de manera incompatible con versiones anteriores. Por lo tanto, estos cambios permiten a los desarrolladores abandonar partes de la API que se eliminarán o no serán compatibles en el futuro. [50]
El 19 de febrero de 2020, Akamai publicó su informe anual "Estado de Internet", que muestra la creciente tendencia de los ciberdelincuentes a apuntar a plataformas API públicas en servicios financieros en todo el mundo. Desde diciembre de 2017 hasta noviembre de 2019, Akamai fue testigo de 85.420 millones de ataques de violación de credenciales. Alrededor del 20%, o 16,55 mil millones, estaban en contra de nombres de host definidos como puntos finales de API. De ellos, 473,5 millones se han dirigido a organizaciones del sector de servicios financieros. [51]
La documentación de API describe los servicios que ofrece una API y cómo utilizar esos servicios, con el objetivo de cubrir todo lo que un cliente necesitaría saber con fines prácticos.
La documentación es crucial para el desarrollo y mantenimiento de aplicaciones que utilizan la API. [52] La documentación de API se encuentra tradicionalmente en archivos de documentación, pero también se puede encontrar en redes sociales como blogs, foros y sitios web de preguntas y respuestas. [53]
Los archivos de documentación tradicionales suelen presentarse a través de un sistema de documentación, como Javadoc o Pydoc, que tiene una apariencia y estructura consistentes. Sin embargo, los tipos de contenido incluidos en la documentación difieren de una API a otra. [54]
En aras de la claridad, la documentación de la API puede incluir una descripción de las clases y métodos de la API, así como "escenarios de uso típicos, fragmentos de código, fundamentos de diseño, discusiones sobre rendimiento y contratos", pero los detalles de implementación de los servicios de la API en sí suelen ser omitido.
La documentación de referencia para una API REST se puede generar automáticamente a partir de un documento OpenAPI, que es un archivo de texto legible por máquina que utiliza un formato prescrito y una sintaxis definida en la Especificación OpenAPI . El documento OpenAPI define información básica como el nombre y la descripción de la API, además de describir las operaciones a las que la API proporciona acceso. [55]
La documentación de la API se puede enriquecer con información de metadatos como anotaciones de Java . Estos metadatos pueden ser utilizados por el compilador, las herramientas y el entorno de ejecución para implementar comportamientos personalizados o un manejo personalizado. [56]
En 2010, Oracle Corporation demandó a Google por haber distribuido una nueva implementación de Java integrada en el sistema operativo Android. [57] Google no había obtenido ningún permiso para reproducir la API de Java, aunque se había otorgado permiso al proyecto similar OpenJDK. Google se había acercado a Oracle para negociar una licencia para su API, pero fue rechazada por problemas de confianza. A pesar del desacuerdo, Google optó por utilizar el código de Oracle de todos modos. El juez William Alsup dictaminó en el caso Oracle v. Google que las API no pueden tener derechos de autor en los EE. UU. y que una victoria de Oracle habría ampliado ampliamente la protección de los derechos de autor a un "conjunto funcional de símbolos" y habría permitido la protección de derechos de autor de comandos de software simples:
Aceptar el reclamo de Oracle sería permitir que cualquiera tenga derechos de autor sobre una versión del código para ejecutar un sistema de comandos y, por lo tanto, impedir que todos los demás escriban sus diferentes versiones para ejecutar todos o parte de los mismos comandos. [58] [59]
El fallo de Alsup fue revocado en 2014 en una apelación ante el Tribunal de Apelaciones del Circuito Federal , aunque la cuestión de si dicho uso de API constituye un uso justo quedó sin resolver. [60] [61]
En 2016, después de un juicio de dos semanas, un jurado determinó que la reimplementación de la API de Java por parte de Google constituía un uso legítimo , pero Oracle se comprometió a apelar la decisión. [62] Oracle ganó en su apelación, y el Tribunal de Apelaciones del Circuito Federal dictaminó que el uso de las API por parte de Google no calificaba para el uso justo. [63] En 2019, Google apeló ante la Corte Suprema de los Estados Unidos sobre las sentencias sobre derechos de autor y uso legítimo, y la Corte Suprema concedió la revisión. [64] Debido a la pandemia de COVID-19 , las audiencias orales del caso se retrasaron hasta octubre de 2020. [65]
El caso fue decidido por la Corte Suprema a favor de Google con una sentencia de 6 a 2. El juez Stephen Breyer emitió la opinión del tribunal y en un momento mencionó que "el código declarante, si es que tiene derechos de autor, está más lejos que la mayoría de los programas de computadora del núcleo de los derechos de autor". Esto significa que el código utilizado en las API se parece más a diccionarios que a novelas en términos de protección de derechos de autor. [66]
Cuando escucha el acrónimo "API" o su versión ampliada "Interfaz de programación de aplicaciones", casi siempre se refiere a nuestro enfoque moderno, en el que utilizamos HTTP para proporcionar acceso a datos legibles por máquina en formato JSON o XML, a menudo simplemente denominadas "API web".
Las API han existido casi tanto tiempo como la informática, pero las API web modernas comenzaron a tomar forma a principios de la década de 2000.