Diferencia entre REST y WebServices

Question

Cuál es la diferencia entre REST y WebService (SOAP), miré la API de Facebook, usan encabezados HTTP y algunos parámetros (probablemente xml o no) y devuelven el resultado en xml, donde SOAP hace exactamente mismo, encabezados HTTP + parámetros xml y devuelve encabezados + xml.

REST también requiere un token autenticado en otro lugar SOAP utiliza la sesión http que es exactamente el mismo token utilizado para la autenticación y otra información. ¿Todo lo que puedo ver es que SOAP es una pequeña versión avanzada de REST?

¿O hay alguna otra consideración de rendimiento? Leer sobre REST solo habla un nivel muy alto de comunicación con el servidor cliente, pero incluso SOAP hace exactamente lo mismo. ¿Alguien puede indicarme dónde puede definir el límite correcto de REST y SOAP?

Utilizamos gran cantidad de SOAP de manera transparente en .net, sin embargo, solo quiero saber si realmente vale la pena pagar una corrección a REST, donde actualmente todo funciona de forma extraordinariamente fluida.

Sé que REST es una arquitectura y SOAP es un protocolo pero mi pregunta es en detalle que actualmente la implementación de ASP.NET WebService de SOAP tiene arquitectura REST?

Answer 1

SOAP es un protocolo para enviar/recibir datos a través de HTTP como XML.

Un servicio web típico será unos pocos métodos, un WSDL que describe cómo llamarlo. No existe una convención real sobre cómo deberían estructurarse, por lo que siempre se necesita mucha documentación de API.

que normalmente será algo así como (para ASP.NET):

• HTTP POST a mysite.com/products.asmx/ListAllProducts - Devuelve la lista de productos XML
• HTTP POST a mysite.com/products.asmx/GetProduct - devuelve XML para el producto basado en SOAP XML en el contenido publicado
• HTTP POST a mysite.com/products.asmx/UpdatePr oducto - Cambios en la información basada en XML SOAP en el contenido publicado

REST es más de una convención para la estructuración de todos sus métodos:

• HTTP GET de mysite.com/products - retornos XML o JSON listado de todos los productos
• HTTP GET de mysite.com/products/14 - devuelve XML o JSON para el producto 14
• HTTP POST a mysite.com/products/14 - cambia el producto 14 a lo que publica en el formulario HTML.
• HTTP DELETE-mysite.com/products/14 - quita producto 14
• HTTP PUT-mysite.com/productos - agrega un nuevo producto

Así que REST funciona más como lo que cabría esperar con las URL del navegador. De esa manera es más natural y como una convención es mucho más fácil de entender. Todas las API REST funcionan de manera similar, por lo que no pasa tanto tiempo aprendiendo las peculiaridades de cada sistema.

Answer 2

Para mí, un servicio implementado con un enfoque RESTful gana uno que usa SOAP o RPC en términos de su accesibilidad. En un sistema relativamente cerrado donde las herramientas están disponibles para generar stubs y lazos basados ​​en un WSDL, esto no es terriblemente importante. Sin embargo, si desea crear servicios accesibles y disponibles para una amplia gama de clientes, la uniformidad de los servicios REST y la facilidad con la que pueden ser consumidos es una gran ventaja, es decir, no necesita una gran pila de RPC, solo la capacidad de hacer solicitudes HTTP.

No estoy seguro si esto responde totalmente su pregunta, pero si, como usted dice, tiene un sistema que funciona basado en SOAP (y controla el cliente y el servidor), entonces no veo ningún motivo para cambiar. Además, algunos servicios se prestarán naturalmente más al acceso basado en RPC, en cuyo caso una interfaz SOAP será más apropiada.

En términos de rendimiento, una o más capas se eliminarían efectivamente de las pilas de tecnología de cliente y servidor si no usa SOAP, para que todo lo demás sea igual, un servicio que exponga una interfaz RESTful ganará allí.