Mensajes SOAP en el servicio web basado en REST

Question

Descargo de responsabilidad: Estoy realmente confundido entre REST y servicios basados ​​en SOAP.
Después de leer muchos tutoriales (que parecen contradictorios entre sí) sobre el servicio web basado en REST, me preguntaba si podemos/debemos usar SOAP para enviar/recibir mensajes en un servicio web basado en REST.
me trataron siguientes enlaces
1) http://www.ibm.com/developerworks/webservices/library/ws-restful/

2) http://rest.elkstein.org/2008/02/how-simple-is-rest.html

Answer 1

por "servicios basados ​​en SOAP" Me suponen que está significando WS-I Basic Profile servicios web. La distinción es importante porque SOAP se puede usar con REST y con los servicios web de WS-I BP. Dejame explicar.

SOAP es un formato de mensajería basado en XML para el intercambio de datos. Soap también define un medio para realizar llamadas a procedimientos remotos. SOAP es un estándar abierto del W3C. SOAP es agnóstico sobre la capa de transporte subyacente. Con frecuencia, HTTP se utiliza como capa de transporte, pero puede ejecutarse felizmente en SMTP y TCP, y también en otros transportes.

REST es un estilo arquitectónico (no es un estándar), así que tenga cuidado de no comparar REST y SOAP directamente porque no está comparando manzanas con manzanas. REST toma HTTP y lo usa de la manera en que debe ser utilizado, con todas sus sutilezas y riqueza. El estilo arquitectónico REST se puede utilizar para transferir datos en cualquier formato; no impone ningún formato de datos en particular. Así que SOAP es un formato de serialización perfectamente bueno para un servicio web de estilo REST. Pero mucha gente usa JSON, XML, texto plano y muchos otros formatos con REST. También puede intercambiar datos binarios por REST, como archivos de imagen. Lo bueno es que puedes elegir el formato de datos que tenga más sentido para tu aplicación.

Tenga en cuenta que dado que REST es un patrón, no un estándar, hay mucho debate sobre lo que significa ser realmente RESTful. Existe un concepto llamado Richardson Maturity Model que establece una serie de pasos hacia el ideal de REST. Al comparar con el modelo de Richardson, podemos ver exactamente qué tan RESTful es una implementación de REST en particular. Los servicios web de WS-I BP están en el nivel 0 en esta escala (es decir, no son muy RESTful en absoluto, solo usan HTTP como una capa de transporte tonta).

Yo diría esto sobre elegir servicios web REST vs WS-I Basic Profile - depende de su audiencia. Si está desarrollando una interfaz de tipo B2B dentro de una empresa, es más común ver los servicios web de WSI-BP. Debido a que existe un estándar subyacente, y debido al soporte maduro de los proveedores empresariales (como IBM, Oracle, SAP, Microsoft) y debido al nivel de soporte de framework especialmente en .NET y Java, WSI-BP tiene mucho sentido cuando necesita que algo funcione rápidamente y quiere facilitar que los clientes se conecten en un entorno empresarial, y los datos intercambiados son datos comerciales que se serializan muy bien como SOAP.

Por otro lado, si está exponiendo servicios web a una audiencia web más amplia, diría que ha habido una tendencia que va desde WSI-BP hacia el estilo RESTful. Como REST solo asume que el cliente admite HTTP, se puede hacer para que funcione con la audiencia más amplia posible. REST también le ofrece la escalabilidad de la propia web, con el soporte para el almacenamiento en caché de recursos, etc., lo que hace que se amplíe a una gran audiencia mucho mejor que los servicios web de WSI-BP.