¿Cómo era la web antes de que los principios REST se usaran ampliamente?

Yo diría que la principal diferencia es:

• SOAP intenta superar los límites
• REST crea límites

Mucho de esta manera:

GET, PUT y col.

La versión abstracta de REST (Transferencia de estado de representación) también es parte de la implementación de HTTP en sí misma y fue más o menos como un concepto de “servicio web”.

Entonces, sí, las solicitudes GET, POST, etc. ya eran términos comunes en HTTP y REST las tomó prestadas como términos literales y como conceptos.

Más allá del paradigma GET, PUT, POST, DELETE, los servicios REST tampoco están realmente estandarizados. No es realmente un protocolo, más una convención.

Aplicaciones distribuidas

El jabón es un animal completamente diferente. Intenta abstraer la capa de transporte (HTTP). Por ejemplo, también puede ejecutarse sobre SMTP (el protocolo de correo electrónico).
Supongo que el enfoque SMTP nunca tuvo mucha tracción y la gente terminó usando HTTP de todos modos.

SOAP también es mucho más ambicioso y más en la línea de CORBA. Básicamente es compatible con aplicaciones distribuidas, donde los objetos del mismo programa están realmente en servidores diferentes e intercambian métodos en un nivel muy bajo.

Entonces SOAP no tiene un vocabulario fijo en absoluto. No encontrarás GET, PUT, etc.

Sin embargo, creo que la mayoría de los servicios SOAP terminaron siendo simples servicios de entrega de datos. Sin embargo, para esa simple tarea, SOAP era demasiado complejo y tenía demasiada sobrecarga.

De vuelta a lo basico

REST es una simplificación, volviendo a lo básico de un tipo específico de interacción , similar a tendencias como dispositivos dedicados o aplicaciones móviles. Hace una cosa, simple y eficientemente, pero no tiene un gran alcance.

La razón principal, veo para REST, es separar las fuentes de datos de los backends. El enfoque API es un buen ejemplo, creo, es decir, puede abstraer su fuente de datos y ponerla a disposición de un tercero, mientras que su propio sitio web también la utiliza. Resultado: mantiene un solo servicio REST que sirve a ambos. Por lo tanto, es una reacción a la mayor demanda de tener opciones para acceder a las bases de datos y alejarse de las conexiones directas del servidor db y las consultas SQL.

(Descargo de responsabilidad: he cepillado ambas tecnologías y un poco de CORBA en mi tiempo. DESCANSE más que las otras, ya que se vuelve más popular, por supuesto. Pero, por favor, siéntase libre de corregir, si entendí mal algo).

Una gran parte de la confusión es que SOAP es un protocolo de aplicación y REST es una recomendación arquitectónica sobre cómo se deben restringir los servicios web.

Sospecho que es posible que haya recurrido a la transferencia de estado de representación que tiene la línea confusa

El estilo arquitectónico REST también se aplica al desarrollo de servicios web [6] como una alternativa a otras especificaciones de computación distribuida como SOAP.

así que ignórelo y observe que el servicio web dice:

Las API RESTful no requieren protocolos de servicios web basados ​​en XML (SOAP y WSDL) para admitir sus interfaces.

lo que indica que si está utilizando los principios REST, entonces no necesita un protocolo de servicio también.

GET y POST han existido desde HTTP 1.0 y no han cambiado. REST solo dice que si los usa de manera organizada, las cosas serán más fáciles de entender y ofrecerán más flexibilidad.

Por lo tanto, concéntrese en las restricciones arquitectónicas de REST, ignore SOAP, y debería poder darle más sentido, o al menos ser capaz de formular una pregunta más precisa.