Header Ads Widget

Ticker

6/recent/ticker-posts

¿Quién inventó la API?

 ¿Qué es una API? ¿Quién fue el primero en usar uno? ¿Alguien "inventó" la API como la conocemos?

Estas preguntas son fundamentales para la programación informática y fundamentales para la industria tecnológica en su conjunto. Si bien son de alto nivel, ciertamente también tienen algunas implicaciones legales importantes, como hemos visto en eventos recientes .

Hoy, abordamos algunos puntos básicos relacionados con las API con el objetivo de comprender algunas preguntas que se filtran en el espacio de las API. Veremos la historia de la API y definiremos la naturaleza del concepto de API en sí. Luego, analizaremos en profundidad algunos de los problemas que rodean a la API moderna en un sentido legal .

¿Quién inventó la API?

La pregunta de quién inventó la API es un poco como preguntar quién descubrió la Antártida: las respuestas son tan variadas como las partes que las envían, y hay poco acuerdo sobre una fecha fija y rápida. La pregunta se vuelve aún más compleja debido a la naturaleza de una API (que discutiremos en breve); dicho esto, al menos podemos comenzar con algunas de las primeras formaciones conceptuales hacia la idea de una API con el trabajo de Wilkes , Wheeler y Gill .

Este artículo se inspiró en una excelente presentación " Una historia breve y con opiniones de la API ", realizada por Joshua Bloch en QCon.

API primordiales

Maurice Vincent Wilkes, parte del equipo detrás de EDSAC. [Fuente:  Wikipedia]

Muchos consideran que Maurice Wilkes, David Wheeler y Stanley Gill son los padrinos de la programación y el software, y por muy buenas razones: su trabajo en los años 40 y 50 sentaría las bases de gran parte de lo que se convertiría en la revolución del software de la Años 70 y 80. Esta revolución sería fundamental en el desarrollo de la informática personal y, por lo tanto, en la casi ubicuidad de los dispositivos personales que disfrutamos hoy.

En 1949, se dio vida a EDSAC , o la calculadora automática de almacenamiento con retardo electrónico . Utilizando complejos sistemas de almacenamiento retardado de mercurio, EDSAC era extremadamente poderoso para la época. Después de darse cuenta durante el desarrollo de su primer programa no trivial de que pasaría el resto de su vida depurando sus propios programas, Wilkes encabezó el trabajo en las bibliotecas de programas que se introdujeron para EDSAC en 1951. Este trabajo se centró en la coordinación de pedidos, lo que permitió el aumento de los pedidos iniciales para permitir subrutinas complejas. El Wheeler Jump fue diseñado durante este tiempo, lo que permite funciones de alto orden utilizando una técnica de enlace de subrutinas para llamar a otras rutinas a una profundidad específica.

La capacidad de memoria principal del EDSAC era de 512 palabras de 18 bits, lo que llenaba una gran sala.

Todo esto surgió bajo la biblioteca de subrutinas de EDSAC , que era literalmente una biblioteca de tarjetas perforadas de papel que contenían las diversas subrutinas. Esto fue publicado en La preparación de programas para una computadora digital electrónica. En ese momento, este trabajo no se denominaba estrictamente una interfaz de programación de aplicaciones, simplemente debido al hecho de que todo era monolítico : no había arquitecturas en competencia, ni programas heredados, y todo estaba en un solo sistema. Dicho esto, esta es posiblemente la primera encarnación verdadera del concepto de API .

Relacionado: Oracle vs. Google: Cómo proteger una API de inconvenientes legales

La máquina en evolución

Por supuesto, EDSAC no fue la última computadora construida, y debido a esto, a medida que se introdujo nuevo hardware, se diseñaron nuevos algoritmos y se integraron nuevos componentes en las bases de código existentes, la necesidad de trasladar la funcionalidad a varios hardware y sistemas en general se hizo obvia y urgente. .

Diagrama de flujo de "Planificación y codificación de problemas para un instrumento de computación electrónica", 1947 [Fuente: Wikimedia Foundation ]

Quizás la declaración conceptual más importante en torno a este problema se encuentra en Planificación y codificación de problemas para un instrumento de computación electrónica de Herman Goldstine y John von Neumann - Parte II, Volumen III. En este volumen, se planteó la idea de que la mayoría de los programas tendrán que utilizar operaciones comunes y una biblioteca de subrutinas . Este concepto establecía que la integración de una biblioteca conocida daría como resultado una reducción drástica en la cantidad de código nuevo que debía desarrollarse, así como en la incidencia de errores y problemas. Desafortunadamente, esta era una visión muy generalizada del concepto de API y, como tal, no ofrecía mucho en cuanto a implementación u orientación, hasta el punto de que algunos expertos modernos lo consideran similar a "vaporware ”, que promete mucho, pero ofrece muy poco.

Finalmente, en 1968, el término se usó por primera vez de manera clara en el documento Data Structures and Techniques for Remote Computer Graphics , que se presentó en la AFIPS Fall Joint Computer Conference de 1968 . En cuanto a 2018, Merriam-Webster lo cita como el primer uso del término "interfaz de programación de aplicaciones" , definiendo el concepto como una promoción de la interoperabilidad entre una variedad de componentes y sistemas.

La conclusión clave de todo esto es una simple comprensión de que es una naturaleza fundamental de las API: las API no se “crean” realmente tanto como se “descubren” . Cualquier uso de una biblioteca entre diferentes aplicaciones y sistemas necesariamente resultará en la necesidad de vincular esos usos, y esta vinculación es la definición literal de una API. La pregunta sobre cuál fue la "primera" API es realmente insignificante: la clave real para definir qué es realmente una API .

Consulte también: Cumplimiento de las nuevas y estrictas normas de la UE sobre protección de datos

¿Qué es una API?

Desafortunadamente, incluso esa es una pregunta equivocada. Una API es solo una interfaz entre dos implementaciones. Las preguntas reales que deberíamos hacernos son  qué tipo de API tenemos y cuál es la naturaleza de esa API .

En nuestra perspectiva moderna, una API web es una puerta inteligente y programable para que los desarrolladores accedan a los datos de una organización digital.

En términos generales, algo es una API si hace dos cosas: primero, debe proporcionar un conjunto de operaciones definidas por entradas y salidas; y segundo, debería permitir la reimplementación sin comprometer a sus usuarios. Por lo general, esto puede verse limitado aún más por sugerencias de que una API debería aumentar un lenguaje de programación o un conjunto de lenguajes. Algunos consideran que ese último aspecto es demasiado restrictivo, ya que omite algo así como un conjunto de instrucciones, que es en gran medida una API de "hardware". Para otros, ese es el punto, y omitir esa restricción hace que la definición sea demasiado amplia. De cualquier manera, cuando empezamos a analizar las API, podemos clasificarlas en dos categorías generales: API de dispositivo  y  API web .

Una API de dispositivo es aquella que permite la comunicación a nivel de dispositivo, normalmente entre el hardware y el software y los componentes interrelacionados que los habilitan. Sin embargo, una API web es diferente porque permite que los dispositivos se comuniquen entre sí a través de diferentes lenguajes, estructuras y arquitecturas.

En esencia, una API web permite la comunicación entre dispositivos casi al considerar cada dispositivo completo como un componente en un dispositivo omnibus de Internet mucho más grande e interconectado: un "dispositivo de dispositivos", por así decirlo. De la misma manera que una API de dispositivo permite que los componentes individuales trabajen juntos, una API web permite que los dispositivos individuales hagan lo mismo.

Para obtener más información, lea: ¿Qué es una API?

Preocupaciones legales sobre las API

Entonces, ¿por qué es todo esto importante? En este momento, nos encontramos en un lugar muy interesante en lo que respecta a las cuestiones legales relacionadas con las API. Durante años, el éxito de las API y los sistemas que permiten dependía de la idea de la reimplementación . Ser capaz de transformar el código una y otra vez permitió nuevas API y nuevas funciones; en muchos sentidos, la interoperabilidad de una API es casi secundaria a su reutilización en términos de lo que hace que la tecnología sea exitosa.

A pesar de eso, ha habido algunas preocupaciones legales en torno al concepto de redacción de textos publicitarios de una API. En 2010, Oracle inició una demanda contra Google con respecto a la implementación de las API de Java en Android, alegando que Google violó tanto su patente como sus derechos de autor. En 2012, un jurado dictaminó que no hubo infracción de patente, y el juez presidente dictaminó que no hubo infracción de derechos de autor, ya que las API no pueden ser redactadas. En 2013, Oracle apeló esta decisión, y en 2014, el Tribunal de Apelaciones del Distrito Federal de EE. UU. Que preside revocó la sentencia original. Más tarde ese año, Google solicitó a la Corte Suprema que escuchara el caso, lo que se negaron a hacer al año siguiente, remitiendo el asunto a los tribunales inferiores.

En 2016, el jurado del Tribunal Federal determinó que el uso era de uso justo , lo que fue apelado por Oracle ante la CAFC. En 2017, Stanford y 76 científicos e ingenieros presentaron un escrito de amicus en apoyo de la reimplementación, pero en 2018, la Corte de Apelaciones de EE. UU. Para el Distrito Federal revirtió nuevamente el hallazgo de la corte inferior y declaró que no era de uso justo . Desde entonces, Google ha solicitado una audiencia en banco.

Esto nos lleva a donde estamos hoy. A finales de 2018, parece  que puede aplicar derechos de autor a una API , lo que supone un cambio radical con respecto a los 75 años anteriores de reimplementación relativamente gratuita. Tal como está, no se puede implementar una API sin los permisos explícitos de su autor. Al autor se le concede un monopolio casi perpetuo sobre la API, con sus derechos de autor que se extienden a 70 años después de la vida del autor, o un total de 95 años para trabajos de empresas y grupos.

Hay algunos argumentos sólidos en ambos lados. Por un lado, algunos consideran que los esfuerzos para crear API masivas son trabajos creativos y, en esos casos, es difícil argumentar que no deberían protegerse. Como contrapunto, el argumento a favor del derecho a la reimplementación es que los nuevos participantes pueden competir mejor con los titulares, lo que se traduce en una mayor interoperabilidad, menos gastos generales y menos tiempo dedicado a litigar intercambiado con mayor tiempo de construcción.

Relacionado: Una guía humana para redactar la política de la plataforma API

Conclusión

En última instancia, esta pieza no está diseñada para argumentar a favor o en contra de la redacción publicitaria de las API, sino que busca proporcionar un contexto tanto para la historia como para el futuro cercano del panorama de las API. Ya sea que las API vuelvan o no a su pasado histórico relativamente libre y abierto o si continúan siendo consideradas “ propiedad intelectual ” con derechos de autor, este tema solo se volverá más complejo y complicado.

Publicar un comentario

0 Comentarios