asp.net - pages - javascript asp net

Diferencia entre REST y WebServices (2)

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

REST también requiere algún token autenticado, en el que SOAP usa 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 otras consideraciones 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?

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

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

Para mí, un servicio implementado utilizando 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 que sean accesibles y estén disponibles para una amplia gama de clientes, la uniformidad de los servicios REST y la facilidad con la que pueden consumirse 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 a su pregunta, pero si, como usted dice, tiene un sistema que funciona basado en SOAP (y usted 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 del cliente y del servidor si no usa SOAP, para que todo lo demás sea igual, un servicio que exponga una interfaz RESTful ganará allí.

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

Un servicio web típico serán algunos 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.

Normalmente, esto será algo así como (para ASP.NET):

HTTP POST a mysite.com/products.asmx/ListAllProducts - devuelve una lista XML de productos
HTTP POST a mysite.com/products.asmx/GetProduct - devuelve XML para producto basado en SOAP XML en el contenido publicado
HTTP POST a mysite.com/products.asmx/UpdateProduct - cambia el producto basado en SOAP XML en el contenido publicado

REST es más una convención para estructurar todos sus métodos:

HTTP GET de mysite.com/products - devuelve XML o JSON que enumera 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 publicas en el formulario HTML.
HTTP DELETE a mysite.com/products/14 - elimina el producto 14
HTTP PUT a mysite.com/products : agrega un nuevo producto

Por lo tanto, REST funciona más como lo haría 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.