Una interfaz de programación de aplicaciones (API) es una forma en que dos o más programas o componentes informáticos se comunican 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 usar dicha conexión o interfaz se denomina especificación de 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 interactúan sus usuarios finales 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á destinada a ser utilizada directamente por una persona (el usuario final ) que no sea un programador de computadoras que la incorpora al software. Una API a menudo se compone de diferentes partes que actúan como herramientas o servicios que están disponibles para el programador. Se dice que un programa o un programador que usa 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 de 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 manteniendo su coherencia incluso si los detalles internos cambian más adelante. Una API puede ser personalizada para un par de sistemas en particular o puede ser un estándar compartido que permita la interoperabilidad entre muchos sistemas.
Existen API para lenguajes de programación , bibliotecas de software , sistemas operativos de computadoras y hardware de computadoras . Las 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 que están unidas por Internet . Los desarrollos recientes en API han llevado al aumento de la popularidad de los microservicios , que son servicios acoplados de forma flexible a los que se accede a través de API públicas. [3]
Las API deben tener versiones . Existen dos estrategias de control de versiones comunes: [4]
Al crear aplicaciones, una API simplifica la programación al abstraer la implementación subyacente y exponer únicamente los objetos o acciones que necesita el desarrollador. Mientras que una interfaz gráfica para un cliente de correo electrónico puede proporcionar al usuario un botón que realiza todos los pasos para buscar y resaltar nuevos correos electrónicos, una API para la entrada y salida de archivos puede brindar al desarrollador una función que copia un archivo de una ubicación a otra sin necesidad de que el desarrollador comprenda las operaciones del sistema de archivos que ocurren detrás de escena. [5]
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, el término es más amplio e incluye también software de utilidad e incluso interfaces de hardware . [7]
La idea de API es mucho más antigua que el término en sí. Los 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 perforadas organizadas en un archivador . Este archivador 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, un catálogo de este tipo se llamaría API (o una especificación de API o documentación de API) porque instruye a un programador sobre cómo usar (o "llamar") cada subrutina que el programador necesita. [7]
El libro de Wilkes y Wheeler de 1951, The Preparation of Programs for an Electronic Digital Computer, contiene la primera especificación API publicada. Joshua Bloch considera que Wilkes y Wheeler "inventaron latentemente" la API porque es más un concepto que se descubre que se inventa. [7]
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 de computadora remotos presentado en una conferencia de AFIPS en 1968. [9] [7] 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 consiste en llamadas a subrutinas Fortran ) tenía como objetivo liberar al programador de lidiar con idiosincrasias del dispositivo de visualización de gráficos y proporcionar independencia de hardware si se reemplazaba la computadora o la pantalla. [8]
El término fue introducido en el campo de las bases de datos por CJ Date [10] en un artículo de 1974 llamado The Relational and Network Approaches: Comparison of the Application Programming Interface [11] . Una API se convirtió en 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 en la década de 1970 observaron que estas diferentes interfaces podían combinarse; una interfaz de aplicación lo suficientemente rica también podría soportar las otras interfaces. [6]
Esta observación condujo a la creación de 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 ciertas tareas" . [12]
La idea de la 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 querían llamar a bibliotecas ubicadas no solo en sus computadoras locales sino en computadoras ubicadas en otros lugares. Estas llamadas a procedimientos remotos fueron bien soportadas por el lenguaje Java en particular. 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. [13]
La disertación de Roy Fielding, Estilos arquitectónicos y diseño de arquitecturas de software basadas en redes en la UC Irvine en 2000, describió la transferencia de estado representacional (REST) y la idea de una "interfaz de programación de aplicaciones basada en red" que Fielding contrastó con las API tradicionales "basadas en bibliotecas". [14] Las API web XML y JSON tuvieron una adopción comercial generalizada a partir de 2000 y continúan hasta 2022. La 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. [15] Las interfaces y agentes propietarios se generalizaron más que los abiertos, pero la idea de la API como una 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. [13] Cuando se utiliza de esta manera, el término API tiene un superposición de significado 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 sola API puede tener múltiples implementaciones (o ninguna, siendo abstracto) 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 lenguaje utilicen una biblioteca escrita en otro. Por ejemplo, debido a que Scala y Java se compilan en bytecode compatible , los desarrolladores de Scala pueden aprovechar cualquier API de Java. [16]
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 . [17] [18] La ley de Hyrum establece que “con un número suficiente de usuarios de una API, no importa lo que prometas en el contrato: todos los comportamientos observables de tu sistema dependerán de alguien”. [19] 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. [20]
Los enlaces de lenguaje también son API. Al asignar las características y capacidades de un lenguaje a una interfaz implementada en otro lenguaje, un enlace de lenguaje permite que una biblioteca o servicio escrito en un lenguaje se use cuando se desarrolla en otro lenguaje. [ cita requerida ]
Herramientas como SWIG y F2PY, un generador de interfaces de Fortran a Python , facilitan la creación de dichas interfaces. [21]
Una API también puede estar relacionada con un marco de software : un marco puede estar basado en varias bibliotecas que implementan varias API, pero a diferencia del uso normal de una API, el acceso al comportamiento integrado en el marco se media extendiendo su contenido con nuevas clases incorporadas al marco mismo.
Además, el flujo de control general del programa puede quedar fuera del control del llamador y en manos del marco mediante una inversión de control o un mecanismo similar. [22] [23]
Una API puede especificar la interfaz entre una aplicación y el sistema operativo . [24] POSIX , por ejemplo, proporciona un conjunto de especificaciones API comunes que tienen como objetivo 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. [25]
Microsoft ha demostrado un fuerte compromiso con una API compatible con versiones anteriores, particularmente dentro de su biblioteca API de Windows (Win32), de modo que las aplicaciones más antiguas pueden ejecutarse en versiones más nuevas de Windows utilizando una configuración específica del ejecutable denominada "Modo de compatibilidad". [26]
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 código binario . Por ejemplo, POSIX proporciona API, mientras que Linux Standard Base proporciona una ABI. [27] [28]
Las API remotas permiten a los desarrolladores manipular recursos remotos a través de protocolos de comunicación, estándares específicos de comunicación que permiten que diferentes tecnologías trabajen juntas, independientemente del lenguaje o la 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 desarrollador. [29] [30]
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 remoto, y adquiere el resultado que se utilizará localmente como valor de retorno.
Una modificación del objeto proxy también dará como resultado una modificación correspondiente del objeto remoto. [31]
Las API web son un servicio al que se accede desde dispositivos cliente (teléfonos móviles, 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, normalmente en formato de notación de objetos JavaScript ( JSON ) o lenguaje de marcado extensible ( XML ). Los desarrolladores suelen utilizar las API web para consultar un servidor sobre un conjunto específico de datos de ese servidor.
Un ejemplo podría ser una API de una compañía naviera que se puede agregar a un sitio web enfocado 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 transportista en una base de datos web. Si bien "API web" históricamente ha sido prácticamente sinónimo de servicio web , la tendencia reciente (la llamada Web 2.0 ) se ha estado alejando de los servicios web basados en el Protocolo simple de acceso a objetos ( SOAP ) y la arquitectura orientada a servicios (SOA) hacia recursos web de estilo de transferencia de estado representacional (REST) más directo y arquitectura orientada a recursos (ROA). [32] 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 . [33]
En el ámbito de las redes sociales, las API web han permitido a las comunidades web compartir contenido y datos entre comunidades y aplicaciones. De esta manera, el contenido que se crea en un lugar de forma dinámica se puede publicar y actualizar en múltiples ubicaciones de la web. [34] Por ejemplo, la API REST de Twitter permite a los desarrolladores acceder a los datos básicos de Twitter y la API de búsqueda proporciona métodos para que los desarrolladores interactúen con los datos de búsqueda y tendencias de Twitter. [35]
El diseño de una API tiene un impacto significativo en su uso. [5] 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. [36] El principio de ocultamiento de información describe el papel de las interfaces de programación como habilitantes de 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. [37] Además del principio subyacente anterior, otras métricas para medir la usabilidad de una API pueden incluir propiedades como la eficiencia funcional, la corrección general y la capacidad de aprendizaje para principiantes. [38] 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. [39] Por lo tanto, el diseño de una API intenta proporcionar solo las herramientas que un usuario esperaría. [5]
Una interfaz de programación de aplicaciones puede ser sincrónica o asincrónica . Una llamada API sincrónica es un patrón de diseño donde el sitio de llamada se bloquea mientras se espera que finalice el código llamado. [40] Sin embargo, con una llamada API asincrónica, el sitio de llamada no se bloquea mientras se espera que finalice el código llamado, y en su lugar, se notifica al hilo de llamada cuando llega la respuesta.
La seguridad de la API es muy crítica al desarrollar una API pública. Las amenazas comunes incluyen inyección SQL , ataques de denegación de servicio (DoS), autenticación rota y exposición de datos confidenciales. [41] Sin garantizar las prácticas de seguridad adecuadas, los actores maliciosos 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 la seguridad de conexión adecuada mediante HTTPS , seguridad de contenido para mitigar ataques de inyección de datos y requerir una clave API para usar su servicio. [42] Muchos servicios de API públicos requieren que use una clave API asignada y se negarán a brindar datos sin enviar la clave con su solicitud. [43]
Las API son una de las formas más comunes en que las empresas tecnológicas se integran. Quienes proporcionan y utilizan API son considerados miembros de un ecosistema empresarial. [44]
Las principales políticas para la liberación de una API son: [45]
Un factor importante cuando una API se vuelve pública es su "estabilidad de 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. [49]
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 se marcan con la anotación Java @Beta . [50]
En ocasiones, una API pública puede declarar que algunas partes de la misma están obsoletas o rescindidas. Esto suele significar que una parte de la API debe considerarse candidata a ser eliminada o modificada de manera incompatible con versiones anteriores. Por lo tanto, estos cambios permiten a los desarrolladores dejar de lado partes de la API que se eliminarán o no serán compatibles en el futuro. [51]
El 19 de febrero de 2020, Akamai publicó su informe anual "State of the Internet", que muestra la creciente tendencia de los cibercriminales a atacar plataformas API públicas en servicios financieros de todo el mundo. Desde diciembre de 2017 hasta noviembre de 2019, Akamai fue testigo de 85,42 mil millones de ataques de violación de credenciales. Alrededor del 20%, o 16,55 mil millones, fueron contra nombres de host definidos como puntos finales de API. De estos, 473,5 millones han tenido como objetivo organizaciones del sector de servicios financieros. [52]
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 necesita saber para fines prácticos.
La documentación es crucial para el desarrollo y mantenimiento de aplicaciones que utilizan la API. [53] La documentación de la 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. [54]
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 una estructura uniformes. Sin embargo, los tipos de contenido incluidos en la documentación difieren de una API a otra. [55]
En aras de la claridad, la documentación de la API puede incluir una descripción de las clases y los métodos de la API, así como "escenarios de uso típicos, fragmentos de código, fundamentos de diseño, debates sobre el rendimiento y contratos", pero los detalles de implementación de los servicios de la API en sí generalmente se omiten.
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 y una sintaxis prescritos definidos en la Especificación OpenAPI . El documento OpenAPI define información básica, como el nombre y la descripción de la API, así como también describe las operaciones a las que la API proporciona acceso. [56]
La documentación de la API se puede enriquecer con información de metadatos como las 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. [57]
En 2010, Oracle Corporation demandó a Google por haber distribuido una nueva implementación de Java integrada en el sistema operativo Android. [58] Google no había obtenido ningún permiso para reproducir la API de Java, aunque se le había dado permiso al proyecto similar OpenJDK. Google se había puesto en contacto con Oracle para negociar una licencia para su API, pero fue rechazada debido a problemas de confianza. A pesar del desacuerdo, Google decidió 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 estar sujetas a 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 permitido la protección de los derechos de autor de comandos de software simples:
Aceptar la afirmación de Oracle equivaldría a permitir a cualquiera registrar los derechos de autor de una versión de código para ejecutar un sistema de comandos y, de ese modo, prohibir a todos los demás escribir sus diferentes versiones para ejecutar todos o parte de los mismos comandos. [59] [60]
La decisión de Alsup fue revocada en 2014 en apelación ante el Tribunal de Apelaciones del Circuito Federal , aunque la cuestión de si dicho uso de las API constituye un uso justo quedó sin resolver. [61] [62]
En 2016, tras 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 justo , pero Oracle prometió apelar la decisión. [63] Oracle ganó 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 un uso justo. [64] En 2019, Google apeló ante la Corte Suprema de los Estados Unidos sobre los fallos de derechos de autor y uso justo, y la Corte Suprema concedió la revisión. [65] Debido a la pandemia de COVID-19 , las audiencias orales del caso se retrasaron hasta octubre de 2020. [66]
El Tribunal Supremo falló a favor de Google por 6 votos 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 puede ser protegido por derechos de autor, está más alejado del núcleo del derecho de autor que la mayoría de los programas informáticos". Esto significa que el código utilizado en las API se parece más a los diccionarios que a las novelas en términos de protección de derechos de autor. [67]
Cuando escuchas el acrónimo "API" o su versión ampliada "Application Programming Interface", casi siempre se refiere a nuestro enfoque moderno, en el que usamos HTTP para proporcionar acceso a datos legibles por máquina en un formato JSON o XML, a menudo denominados simplemente "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.