Veo APIs como PayPal, etc. que ofrecen llamar a sus servicios mediante NVP o SOAP/WSDL. Cuando se utiliza un entorno .NET (3.5) utilizando servicios web tradicionales (sin WCF), ¿cuál es mejor y por qué? Sé que WSDL te permite incluir la URL de la API y genera los contenedores para ti. Entonces, ¿por qué las empresas incluso ofrecen NVP?Ventajas de los pares de nombre y valor en SOAP/WSDL
Parece haber confusión sin fin en esta industria sobre los diferentes tipos de servicios web.
SOAP es un protocolo de mensajes . Tiene tanto en común con REST como una manzana con un tractor de césped. Algunas de las cosas que desea en un protocolo de mensajería son:
... y así sucesivamente Esta no es una lista exhaustiva Lo WSDL se suma a SOAP, sobre todo, es:
Discoverability a través de un contrato, una forma legible por la máquina de "documentación" que indica a los consumidores exactamente lo que se requiere con el fin de enviar un mensaje y permite que los proxies para ser auto-generada;
Esquema de validación de mensajes automatizado, del mismo modo que XSD funciona para XML.
REST es no un protocolo de mensajería. REST es un sistema de recursos y acciones. Es una opción sólida para muchas arquitecturas por varias razones importantes, como se indica en otras respuestas. También tiene poca o ninguna relevancia para servicios "NVP" como PayPal y flickr.
La API de NVP de PayPal no es REST. Es un protocolo de mensajería alternativa similar a RPC sobre HTTP POST para clientes que no admiten o tienen dificultades para soportar SOAP. Esta no es mi opinión, es una declaración de hecho. Uno de los campos en el NVP es en realidad METHOD. Esto es claramente RPC verbosidad. Eche un vistazo a su API para UpdateRecurringPaymentsProfile y trate de decirme que esto tiene un toque de sentido para describirlo como un "recurso". No es un recurso, es una operación .
En el caso de PayPal específicamente, la API "NVP" (HTTP POST) es inferior a la API SOAP en casi todos los sentidos. Está ahí para los consumidores que no pueden usar SOAP. Si puede usarlo, definitivamente debe.
Y tampoco estoy necesariamente criticando a PayPal por esto. Sé que mucha gente los ha criticado por no armar una API RESTful "adecuada", pero eso no es lo que estoy tratando de decir. No todos los servicios en el mundo se pueden describir con precisión con REST. PayPal no es realmente un sistema basado en recursos, es un sistema transaccional , por lo que puedo perdonar a sus arquitectos y desarrolladores por no tener una arquitectura REST perfectamente elegante. Es discutible quizás, pero no es en blanco y negro. Está bien; Usaré el sistema SOAP si es necesario.
Compárelo con, por ejemplo, Twitter API. Este es un verdadero servicio REST. Cada "operación" que puede realizar en esta API se describe con precisión como la recuperación o el envío de un tipo de recurso en particular. Un recurso es un tweet, un estado, un usuario.En este caso, literalmente, no tiene sentido utilizar un SOAP API compleja porque usted no está realmente el envío de mensajes, no se está realizando transacciones , estas a pedir cosas específicas , y estas cosas se puede describir con una sola URL. La única diferencia es que en lugar de recuperar una página web HTML, obtiene algunos datos XML o JSON; la forma en que lo solicita es exactamente lo mismo.
Un servicio web REST normalmente (¿siempre?) Utiliza HTTP GET para la recuperación de algún recurso. Y Twitter hace exactamente esto. GET sigue usando "pares nombre-valor": esa es la cadena de consulta, ?q=twitterapi&show_user=true. Esos bits después de ? son pares nombre-valor. Y aquí hay un gran ejemplo de por qué querría usar REST sobre SOAP; puede conectarlo a una fuente RSS y obtener actualizaciones de transmisión. Puedo convertirlo en un marcador activo en Firefox. O puedo descargarlo en formato JSON y vincularlo a algo así como un jqGrid. Lo interesante no es que la solicitud use "Pares nombre-valor"; lo interesante es que es una URL simple y puede ser consumida por cualquier cosa que sepa cómo solicitar una página web.
Así que para tratar de resumir todo lo que he dicho, creo que de esta manera:
Utilice una API REST (si está disponible) cuando se desea exponer datos, o consumir o publicarla , como un recurso permanente.
Utilice una API SOAP cuando el sistema es de naturaleza transaccional y/o cuando necesita las características avanzadas que un protocolo de mensajería complejo puede ofrecer, como RM y direccionamiento.
Utilice una API de RPC (que incluye casi cualquier API modelada completamente en HTTP POST) cuando no hay API SOAP o cuando no puede usar la API de SOAP.
Espero que aclara algo de la confusión.
Supongo que por Name Value Pairs, se refiere a los servicios REST.
Los beneficios para REST son principalmente facilidad de desarrollo, simplicidad y elegancia, y una menor sobrecarga (lo cual es muy importante si está enviando y recibiendo muchos mensajes pequeños).
Estas son algunas de las ventajas de REST:
Aquí está la cosa. La primera vez que usé una API (fue Facebook en particular), codifiqué todas las envolturas a mano. Mi jefe viene a mí y me dice por qué hiciste esto cuando pudiste haber usado el WSDL. Porque de esa manera a) Usted no codifica manualmente ninguna de las envolturas yb) si su API cambia, no necesita volver atrás y cambiar todas sus envolturas y, por lo tanto, c) su aplicación no infringe una API cambio por el proveedor – PositiveGuy
En primer lugar, no es probable que Facebook haga grandes cambios en su API. En segundo lugar, debe escribir envolturas más flexibles (consulte: este ejemplo de código usando la API de Bing - http://msdn.microsoft.com/en-us/library/dd251093.aspx) –
Nombre Pares de valor en este contexto se refiere a poner todo de sus parámetros en un cuerpo POST, (básicamente) codificado en url como 'NAME1 = VALUE1 & NAME2 = VALUE2', y POSTing esa cadena codificada a una sola URL de la API. No relacionado con REST en absoluto, desafortunadamente. –
NVP es POST HTTP
name=fred
amount=100
code=403
etc
Este es el formato por defecto desde cualquier navegador HTML, así que es fácil de implementar para el envío de datos a un servicio web
No creo que sea un buen formato para recibir datos del servicio web. JSON o XML serían más adecuados
No todo el mundo utiliza VisualStudio, o tiene acceso a los generadores de envoltura automática, o quiere usar una bestia tan
Muchos mashups web están codificados en Javascript, por lo que el uso de HTTP POST para enviar datos es la forma más simple. El resultado devuelto es un código de respuesta HTML estándar (200, 403, 500, etc.) y/o algún JSON
Muchos proveedores de servicios ofrecer múltiples API para atender a todos los clientes
Buena explicación/detalle: OMI en su lugar. –
¡muy bien, muchas gracias! – PositiveGuy