¿Por qué se usaría REST en lugar de servicios basados en SOAP? [cerrado]
Asistió a una demostración interesante sobre REST hoy, sin embargo, no podía pensar en una sola razón (ni se presentó una) por la que 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 que alguien en el "mundo real" usa REST en lugar de los Servicios basados en SOAP?
11 answers
Menos sobrecarga (sin sobre de JABÓN para envolver cada llamada)
Menos duplicación (HTTP ya representa operaciones como DELETE, PUT, GET, etc. que de lo contrario tienen que ser representados en un sobre de JABÓN).
Más estandarizadas: las operaciones HTTP se entienden bien y funcionan de manera consistente. Algunas implementaciones SOAP pueden ser meticulosas.
Más legible y comprobable (más difícil de probar SOAP con solo un navegador).
No necesita usar XML (bueno, no tiene para el JABÓN tampoco, pero apenas tiene sentido, ya que ya está haciendo el análisis del sobre).
Las bibliotecas han hecho que SOAP (en cierto modo) sea fácil. Pero usted está abstrayendo un montón de redundancia por debajo como he señalado. sí, en teoría, SOAP puede ir sobre otros transportes para evitar montar encima de una capa haciendo cosas similares, pero en realidad casi todo el trabajo de SOAP que harás es sobre HTTP.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-18 06:18:19
Los servicios RESTful son mucho más simples de consumir que los servicios (regulares) basados en SOAP. La razón de esto es que REST se basa en solicitudes HTTP normales que permiten inferir intent del tipo de solicitud que se está realizando (GET = retrive, POST = write, DELETE = remove, etc.)...) y es completamente apátrida. 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 experience SOAP se ha preferido para los servicios dentro de la empresa y REST se ha preferido para los servicios que se exponen como API públicas.
Con herramientas como WCF en.NET framework es muy trivial implementar un servicio como REST o SOAP.
Alguna lectura relevante:
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-02-22 18:33:24
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 profundizas en los detalles, descubres que ambos enfoques tienen puntos fuertes en diferentes escenarios. ¿Son esos detalles los que te interesan?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-18 06:16:45
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 diseño pobre.
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-25 21:15:44
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 la gente consuma sus datos. Ellos no quieren ser 1000s de desarrolladores novatos que están tratando de depurar la biblioteca SOAP con errores de su lenguaje de scripting de elección.
Frente a SOAP y WSDL, que son mejores para aplicaciones internas, donde tiene drop-in bibliotecas y conocidos clueful personas 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 obtienes API que están auto-documentadas, preservan tipos, etc. sin trabajo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-18 06:43:37
Tengo que leer la más excelente disertación de Roy Fielding sobre el tema. Él hace un caso excelente y estaba definitivamente CAMINO por delante de su tiempo cuando lo escribió (2000).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-03-13 23:37:48
El blog de Steve Vinoski y sus últimos artículos definitivamente vale la pena leer. Es un ex gurú de CORBA, que escribió probablemente el mejor libro sobre el tema con Michi Henning, "Advanced CORBA® Programming with C++". Sin embargo, desde entonces ha visto el error de sus formas cliente/servidor, y ahora jura por REST.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-18 06:24:37
REST permite que sus operaciones no mutantes (que generalmente usan el verbo GET) se almacenen en caché. Es decir, cacheado por el cliente y / o cacheado por proxies. Esto puede ser una gran victoria!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-23 20:16:45
REST es básicamente solo una forma de implementar servicios web. Es solo una forma de usar HTTP correctamente para consultar los servicios web que está tratando de golpear.
Http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-18 06:16:29
Es súper simple y delgado. Puedes hacerlo con el navegador a través del verbo http: GET. No he encontrado un navegador puede hacer manualmente la solicitud http POST genérica fácilmente
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-18 06:38:38
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 un mayor rendimiento.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-07-04 05:53:22