¿Por qué uno usaría REST en lugar de servicios basados ​​en SOAP? [cerrado]

Asistí a una demostración interesante sobre REST hoy, sin embargo, no pude pensar en una sola razón (ni se presentó una) por la cual REST es de todos modos mejor o más simple de usar e implementar que una pila de Servicios basada en SOAP.

¿Cuáles son algunas de las razones por las cuales alguien en el "mundo real" usa REST en lugar de los servicios basados ​​en SOAP?

Menos gastos generales (sin sobre SOAP para envolver cada llamada)

Menos duplicación (HTTP ya representa operaciones como DELETE, PUT, GET, etc. que de otro modo deben representarse en un sobre SOAP).

Más estandarizado: las operaciones HTTP se entienden bien y funcionan de manera consistente. Algunas implementaciones de SOAP pueden ser complicadas.

Más legible y comprobable para los humanos (más difícil de probar SOAP con solo un navegador)

No es necesario usar XML (bueno, tampoco tiene que usar SOAP, pero no tiene sentido ya que ya está analizando el sobre).

Las bibliotecas han hecho SOAP (más o menos) fácil. Pero está abstrayendo mucha redundancia debajo, como he señalado. sí, en teoría, SOAP puede pasar por otros transportes para evitar subir sobre una capa haciendo cosas similares, pero en realidad casi todo el trabajo de SOAP que harás será a través de HTTP.

Los servicios RESTful son mucho más simples de consumir que los servicios basados ​​en SOAP (regulares). La razón de esto es que REST se basa en solicitudes HTTP normales que permiten inferir la intención del tipo de solicitud que se realiza (GET = recuperar, POST = escribir, DELETE = eliminar, etc.) y es completamente sin estado. Por otro lado, podría argumentar que es menos flexible ya que elimina el concepto de un sobre de mensaje que contiene el contexto de la solicitud.

En mi experiencia, SOAP ha sido preferido para servicios dentro de la empresa y REST ha sido preferido para servicios que están expuestos como API públicas.

Con herramientas como WCF en .NET framework, es muy trivial implementar un servicio como REST o SOAP.

Algunas lecturas relevantes:

• Blog de servicios web de Amazon: REST vs SOAP
• Dare Obasanjo escribe a menudo sobre REST

Asumiré que cuando dices "servicios web" te refieres a SOAP y al conjunto de estándares WS- *. (De lo contrario, podría argumentar que los servicios REST son "servicios web").

El argumento canónico es que los servicios REST coinciden más con el diseño de la web, es decir, el diseño de HTTP y la infraestructura asociada. Por lo tanto, el uso de un servicio REST será más compatible con las herramientas y técnicas web existentes.

Por supuesto, una vez que profundice en detalles, descubrirá que ambos enfoques tienen fortalezas en diferentes escenarios. ¿Son esos detalles los que te interesan?

La sobrecarga no es tan importante como una buena arquitectura.

REST no es un protocolo, es una arquitectura que fomenta un buen diseño escalable. A menudo se elige porque demasiada libertad en RPC puede conducir fácilmente a un mal diseño.

La otra razón es el costo predecible de los protocolos RESTful sobre HTTP porque puede aprovechar las tecnologías existentes (principalmente proxies). El costo inicial de RPC es bastante bajo, pero tiende a aumentar significativamente con la intensificación de la carga.

REST es independiente de la implementación y mucho más transparente, y esto lo hace ideal para API públicas, especialmente para grandes sitios web como Flickr, Amazon o Digg que están utilizando sus API como herramientas de marketing y realmente quieren que las personas consuman sus datos. Ellos no quieren ser 1000s mano de retención de los desarrolladores novatos que están tratando de depurar su lenguaje de script de la biblioteca de SOAP con errores de elección.

Versus SOAP y WSDL, que son mejores para aplicaciones internas, en las que tiene bibliotecas integradas y personas claves conocidas en ambos extremos. (Y tal vez no tenga que preocuparse por cosas como el equilibrio de carga a escala de Internet, el almacenamiento en caché HTTP, etc.) Luego obtiene API que están auto documentadas, preservan tipos, etc. con cero trabajo.

Tengo que leer la tesis más excelente de Roy Fielding sobre el tema. Se hace un excelente caso y fue definitivamente MANERA adelantado a su tiempo cuando lo escribió (2000).

El blog de Steve Vinoski y sus últimos artículos definitivamente valen la pena. Es un ex gurú de CORBA, que probablemente escribió el mejor libro sobre el tema con Michi Henning, "Programación avanzada de CORBA® con C ++" . Sin embargo, desde entonces ha visto el error de su cliente / servidor, y ahora jura por REST.

REST permite que sus operaciones no mutantes (que generalmente usan el verbo GET) se almacenen en caché . Es decir, en caché por el cliente y / o en caché por servidores proxy. ¡Esto puede ser una gran victoria!

REST es básicamente una forma de implementar servicios web. Es solo una forma de utilizar HTTP correctamente para consultar los servicios web que está intentando utilizar.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

Es super simple y delgado. Puede hacerlo con el navegador a través del verbo http: GET. No he encontrado un navegador que pueda hacer manualmente la solicitud genérica HTTP POST fácilmente

Aquí hay un punto de datos: Amazon ofrece sus API en formatos REST y SOAP y el 85% del uso es REST.

REST es más fácil de implementar, más fácil de entender y de mayor rendimiento.