¿Por qué las aplicaciones web no utilizaron las API RESTful desde el principio de la web, en lugar de las aplicaciones basadas en formularios?

En los primeros años, las aplicaciones web tenían un fuerte acoplamiento entre la URL y una ruta física a un archivo que contiene el código para un script CGI. Microsoft ASP (1996) o Java JSP (1999) también fueron alternativas comunes al CGI, pero ambos siguieron principalmente el acoplamiento de URL a ruta.

El uso de API RESTful depende del desacoplamiento de la ruta URL de la ruta física. Puedes hacer esto con:

• Reescritura de URL en el servidor http, que es complejo de mantener.
• Servidores de aplicaciones que lo ayudan a definir asignaciones de URL.
• Alguna otra implementación del patrón del controlador frontal, que no se hizo popular hasta aproximadamente 2002.

Esta es una pregunta difícil de responder en mi opinión. No porque la pregunta sea difícil, sino más bien la respuesta, es como preguntar por qué no usamos el correo electrónico en la infancia del fax. Honestamente, aunque se crearon API de alto nivel para permitir a los desarrolladores y / o externos de una empresa tener acceso a la información sin darles acceso a la base de datos. Sucede que esta tecnología funciona para otros casos de uso, aunque POST y GET, y los “ me gusta ” todavía se usan mucho y se seguirán utilizando, ya que todo tiene su propósito. Hay maneras bonitas de hacer POST, etc. con AJAX o similar, una no va a escribir una API solo para que alguien pueda ir a un sitio web y enviar un formulario de contacto, por ejemplo. Las aplicaciones móviles usan muchas API, pero solo porque durante mucho tiempo no existía una forma nativa para que una aplicación móvil se comunicara con una base de datos. Ha habido una tecnología similar antes de las API, pero no es realmente una necesidad. Sin embargo, es una excelente manera de descargar el consumo y la sobrecarga del servidor en muchos escenarios. En resumen, las API no se crearon para reemplazar los métodos tradicionales, se crearon para llenar un vacío y permitir ciertos métodos de acceso que no se proporcionan fácilmente por medios tradicionales para ciertos casos. Su crecimiento también continuará su uso, pero nunca reemplazará por completo los métodos tradicionales para todo. Creo que la mayoría de los programadores estarían de acuerdo en que hasta el día de hoy, cuando se escribe software de circuito cerrado, no hay necesidad del gasto adicional y el dolor de cabeza de escribir una API que es solo un intermediario. Circuito cerrado porque no se necesita acceso a la base de datos fuera del software escrito para interactuar con dicha base de datos, a menos que sea necesario debido a que es una aplicación móvil o similar. Espero que esta respuesta no suene dura, solo requiere mucha explicación y, sinceramente, una investigación de su parte para comprender mejor las complejidades involucradas.

Bueno, estábamos usando la web a principios de los 90 y sus marcos eran muy pocos. Incluso cuando estuve en Amazon desde 95–98, hicimos casi todo en HTML y PERL con CGI en el back-end.

API apareció cuando los frameworks comenzaron a aparecer y el desarrollo web comenzó a estabilizarse y a convertirse en un desorden menos codificado de espagueti. Cuando comenzamos a aplicar muchos de los principios que aprendimos en la codificación regular a este nuevo paradigma.

Los nuevos paradigmas no obtienen de inmediato los beneficios de toda la informática; Nos lleva un tiempo descubrir y adaptar herramientas y reglas al nuevo paradigma.

La respuesta corta es que no existían. La primera interfaz web fue cgi-bin, que fue más o menos diseñada para C y perl, y los formularios HTML se implementaron con eso en mente. De hecho, es realmente la web la que facilitó la API RESTful como mecanismo universal de intercambio de datos.

Porque la tecnología relacionada ajax llega tarde en la imagen. Ajax tardó en ganar tracción y saber cómo hacerlo entre los desarrolladores. Y también es hora de que los casos de uso, como la aplicación de una sola página, sean populares.