¿En qué se diferencian los servicios web RESTful y SOAP en la práctica?

Question

Estoy implementando servicios web para una aplicación PHP y estoy tratando de entender lo que los servicios web estándar y los servicios web RESTful tienen para ofrecer. Mi intención es escribir un código de contenedor para abstraer los detalles del servicio web para que los desarrolladores puedan simplemente "crear instancias de objetos remotos" y usarlos. Éstos son mis pensamientos, tal vez algunos de ustedes podrían añadir su experiencia y ampliar esta:

REST Web Servcies

son básicamente "XML alimenta de la demanda", por lo que, por ejemplo, se podría escribir código de contenedor para una aplicación cliente para que pudiera consultar la aplicación de servidor de esta manera:

$users = Users::getUsers("state = 'CO'"); 

• esto a su vez obtener un feed XML formar una URL remota
• $ usuarios podría convertirse en una colección de objetos de usuario completa, o
• dejaron como XML, o
• convirtieron en una matriz, etc.
• la secuencia de comandos de consulta ("estado = 'CO'") se traduciría en SQL en el lado del servidor

• Los servicios web RESTful son, en general, de solo lectura desde la vista del cliente, aunque podría escribir código que podría usar POST o GET para realizar cambios en el servidor, p. pasando un token cifrado por seguridad, por ejemplo:

  $ users = Users :: addUser ($ encryptedTrustToken, 'jim', $ encryptedPassword, 'James', 'Taylor');

y esto crearía un nuevo usuario en la aplicación del servidor.

servicios web estándar

estándar Web Servcies en el extremo básicamente hacen lo mismo. La única ventaja que tienen es que el cliente puede descubrir sus detalles a través de WSDL. Pero aparte de eso, si quiero escribir un código de envoltura que permita a un desarrollador crear instancias, editar y guardar objetos de forma remota, igual debo implementar el código de envoltura. SOAP no hacer nada de eso para mí, se puede hacer esto:

$soap = new nusoap_client('http://localhost/test/webservice_user.php?wsdl', true); 
$user = $soap->getProxy(); 
$lastName = $user->lastName(); 

pero si quiero editar y guardar:

$user->setLastName('Jones'); 
$user->save(); 

entonces necesito a, por ejemplo manejar todo el estado en el lado del servidor, SOAP no parece mantener ese objeto en el lado del servidor para cada cliente.

Quizás haya limitaciones en la implementación de PHP SOAP que estoy usando (nusoap). Quizás las implementaciones de Java y .NET hacen mucho más.

Disfrutará escuchando sus comentarios para aclarar algunas de estas nubes.

Answer 1

Son modelos diferentes ... REST es centrada en los datos, donde, como SOAP es operación centrada en. es decir, con SOAP tiende a tener operaciones discretas "SubmitOrder", etc .; pero con REST generalmente es mucho más fluido acerca de cómo está consultando los datos.

SOAP también tiende a asociarse con mucha más complejidad (que a veces es necesaria) - REST vuelve a POX, etc., y YAGNI.

---

En términos de .NET, herramientas como "wsdl.exe" le dará una biblioteca proxy del lado del cliente completo para representar un servicio SOAP (o "svcutil.exe" para un servicio WCF):

var someResult = proxy.SubmitOrder(...); 

Para REST con .NET, supongo que ADO.NET Data Services es el reproductor más obvio. Aquí, las herramientas (datasvcutil.exe) le brindarán un contexto de datos completo del lado del cliente con soporte LINQ. LINQ es la forma relativamente nueva de .NET de formar consultas complejas. Así que algo como (con la comprobación fuerte/estática tipo y intelisense):

var qry = from user in ctx.Users 
      where user.State == 'CO' 
      select user; 

(esto se traduce a/de la sintaxis de descanso apropiados para ADO.NET Data Services)

Answer 2

Las principales diferencias son básicamente herramientas .

Muchas de las pilas de SOAP de gama alta cubren la mayor parte de la infraestructura de SOAP del desarrollador, donde usted trabaja casi exclusivamente con DTO/Documents y RPC.

REST a través de HTTP le pone más de esa carga al desarrollador (formatos de negociación [XML, JSON, HTTP POST], resultados de análisis [DOM, mapas, clasificación de DTO, etc.]).

Obviamente, puede escribir una capa de lógica para facilitar el tratamiento de este detalle. Y algunos marcos REST han llegado para hacer esto más fácil, pero por el momento, sigue siendo una tarea en su lista de tareas pendientes cuando desea utilizar o consumir dichos servicios.

Answer 3

Mi opinión es que si desea un estado remoto, no está hablando de servicios web. No conozco ningún modelo contemporáneo que se ocupe del estado remoto. Creo que si necesitas un estado remoto estás a solas (sin religión a seguir). Simplemente tira xml de aquí para allá y no te importe la teoría.

Tengo que agregar que el estado remoto es malo. Evitalo si puedes.

Answer 4

Soap es solo un conjunto de esquemas XML acordados y bendecidos por un grupo de estándares. Su punto fuerte es que fue diseñado para la interoperabilidad y admite muchas características de clase empresarial. Jabón en cualquier plataforma no proporcionará las operaciones que estás buscando. Necesita diseñar & para implementar el contrato de servicio para obtener esas características.

Parece que quieres objetos remotos que ni Soap ni REST son especialmente buenos. Tal vez sería mejor que miraras XML-RPC.

Answer 5

Me hago eco de lo que Marc Gravell mencionó. Cuando las personas me preguntan sobre REST (y generalmente tienen una idea sobre SOAP y SOA), les diré REST = ROA, ya que está orientado a los recursos/datos, es un paradigma diferente y, por lo tanto, tiene preocupaciones de diseño diferentes.

Para su caso, si le leo correctamente, quiere evitar escribir el código del contenedor y necesita una solución que pueda almacenar objetos y sus atributos de forma remota (y tenerlos completamente ocultos para los desarrolladores). Realmente no puedo sugerir una mejor solución ...Umm, quiero saber si cualquiera de éstos cada vez se acercan a satisfacer sus requisitos:

1. EJB3/JPA
2. CouchDB (REST/JSON)

Avísame también si he interpretado su pregunta erróneamente

Si comparamos XML-RPC y SOAP, este último le dará un mejor manejo de tipos de datos, para el primero aunque tratará con tipos de datos más simples, pero tendrá que escribir una capa o adaptador para convertirlos a su objetos de dominio.

yc