Una interfaz de programación de aplicaciones ( API ) es una conexión entre computadoras o entre programas de computadora . 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 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 tanto a la especificación como a la implementación.
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.
El término API se utiliza a menudo para referirse a las API web , [2] que permiten la comunicación entre ordenadores conectados a través de Internet . También existen API para lenguajes de programación , bibliotecas de software , sistemas operativos de ordenadores y hardware de ordenadores . Las API se originaron en la década de 1940, aunque el término no surgió hasta los años 1960 y 1970.
En la creación de aplicaciones, una API (interfaz de programación de aplicaciones) simplifica la programación abstrayendo la implementación subyacente y exponiendo ú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. [3]
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 . [5]
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 de papel 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. [5]
El libro de Wilkes y Wheeler, 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. [5]
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. [7] [5] 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 del hardware si se reemplazaba la computadora o la pantalla. [6]
El término fue introducido en el campo de las bases de datos por CJ Date [8] en un artículo de 1974 llamado The Relational and Network Approaches: Comparison of the Application Programming Interface [9] . 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. [4]
Esta observación dio lugar a las API que admitían todo tipo de programación, no sólo la programación de aplicaciones. En 1990, el tecnólogo Carl Malamud definió la API simplemente como "un conjunto de servicios disponibles para que un programador realice determinadas tareas" . [10]
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. [11]
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". [12] Las API web XML y JSON tuvieron una adopción comercial generalizada a partir de 2000 y continúan hasta 2021. 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 reformulaban la API como una interfaz de datos abierta y distribuida en lugar de una interfaz de comportamiento de software. [13] 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. [11] 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. [14]
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 . [15] [16]
Los enlaces de lenguaje también son API. Al mapear 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. [17] Herramientas como SWIG y F2PY, un generador de interfaces de Fortran a Python , facilitan la creación de dichas interfaces. [18]
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. [19] [20]
Una API puede especificar la interfaz entre una aplicación y el sistema operativo . [21] POSIX , por ejemplo, especifica un conjunto de 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. [22]
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". [23]
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. [24] [25]
Las API remotas permiten a los desarrolladores manipular recursos remotos a través de protocolos , estándares específicos para la comunicación que permiten que diferentes tecnologías trabajen juntas, independientemente del lenguaje o la plataforma. Por ejemplo, la API de conectividad de base 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. [26] [27]
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 resultará en una modificación correspondiente del objeto remoto. [28]
Las API web son las interfaces definidas a través de las cuales se producen las interacciones entre una empresa y las aplicaciones que utilizan sus activos, que también son un Acuerdo de Nivel de Servicio (SLA) para especificar el proveedor funcional y exponer la ruta de servicio o URL para sus usuarios de API. Un enfoque de API es un enfoque arquitectónico que gira en torno a proporcionar una interfaz de programa a un conjunto de servicios para diferentes aplicaciones que atienden a diferentes tipos de consumidores. [29]
Cuando se utiliza en el contexto del desarrollo web , una API se define típicamente como un conjunto de especificaciones, como mensajes de solicitud de Protocolo de transferencia de hipertexto (HTTP), junto con una definición de la estructura de los mensajes de respuesta, generalmente en un formato de Lenguaje de marcado extensible ( XML ) o Notación de objetos JavaScript ( JSON ). 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 históricamente "API web" 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 directos y arquitectura orientada a recursos (ROA). [30] 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 . [31] 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 en un lugar de forma dinámica se puede publicar y actualizar en múltiples ubicaciones en la web. [32] Por ejemplo, la API REST de Twitter permite a los desarrolladores acceder a los datos centrales 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. [33]
El diseño de una API tiene un impacto significativo en su uso. [3] El principio de ocultamiento de información describe el papel de las interfaces de programación como facilitadoras de la programación modular al ocultar los detalles de implementación de los módulos, de modo que los usuarios de los módulos no necesiten comprender las complejidades dentro de los módulos. [34] Por lo tanto, el diseño de una API intenta proporcionar solo las herramientas que un usuario esperaría. [3] El diseño de interfaces de programación representa una parte importante de la arquitectura de software , la organización de una pieza compleja de software. [35]
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. [36]
Las principales políticas para la liberación de una API son: [37]
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. [41]
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 . [42]
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 forma que no sea compatible 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. [43]
El código del cliente puede contener usos innovadores u oportunistas que no fueron previstos por los diseñadores de la API. En otras palabras, para una biblioteca con una base de usuarios significativa, cuando un elemento se convierte en parte de la API pública, puede usarse de diversas maneras. [44] El 19 de febrero de 2020, Akamai publicó su informe anual “State of the Internet”, que muestra la creciente tendencia de los ciberdelincuentes a atacar plataformas de 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. [45]
La documentación de API describe qué servicios 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. [46] 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. [47]
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. [48]
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 propios servicios de la API suelen omitirse. Puede adoptar diversas formas, incluidos documentos instructivos, tutoriales y obras de referencia. También incluirá una variedad de tipos de información, incluidas guías y funcionalidades.
La documentación también cubre las restricciones y limitaciones sobre cómo se puede utilizar la API. Por ejemplo, la documentación de una función de API podría indicar que sus parámetros no pueden ser nulos, que la función en sí no es segura para subprocesos . [49] Debido a que la documentación de API tiende a ser exhaustiva, es un desafío para los escritores mantener la documentación actualizada y para los usuarios leerla con atención, lo que potencialmente genera errores. [41]
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. [50]
Es posible generar documentación de API de manera basada en datos. Al observar muchos programas que utilizan una API determinada, es posible inferir los usos típicos, así como los contratos y directivas necesarios. [51] Luego, se pueden usar plantillas para generar lenguaje natural a partir de los datos extraídos.
En 2010, Oracle Corporation demandó a Google por haber distribuido una nueva implementación de Java integrada en el sistema operativo Android. [52] Google no había obtenido ningún permiso para reproducir la API de Java, aunque sí se había dado permiso al proyecto similar OpenJDK. 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. [53] [54]
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. [55] [56]
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. [57] 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. [58] 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. [59] Debido a la pandemia de COVID-19 , las audiencias orales del caso se retrasaron hasta octubre de 2020. [60]
El caso fue decidido por el Tribunal Supremo a favor de Google. [61]
Cuando escuchas 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 sentido de que usamos HTTP para proporcionar acceso a datos legibles por máquina en 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.
{{cite web}}: CS1 maint: url-status (link)