Salesforce SOAP VS REST

Question

He estado creando una aplicación de consola que utiliza la API SOAP de Saleforce y ahora necesito usar la API de Salesforce en una aplicación web.

¿Es correcto suponer que SOAP es más adecuado para una aplicación no basada en la web, y REST es mejor para una aplicación web?

Si tuviera que crear un contenedor que se utilizaría en informes de aplicaciones locales o publicar en Salesforce desde nuestros sitios web, ¿debería exponer las API REST y SOAP, dependiendo de la aplicación? ¿O debería seguir usando uno? ¿Cuáles son los factores decisivos que debería considerar si solo necesito elegir uno?

Answer 1

Las otras respuestas contienen buena información general, algunas cosas específicas fuerza de ventas a tener en cuenta son

1) Puede actualizar los datos directamente a granel en la API de SOAP, pero tendrá que utilizar la API a granel asíncrono para hacer eso desde REST.

2) La API de jabón contiene algunas cosas que no están disponibles en la API REST, más notablemente describeLayout, queryAll, getDeleted & Getupdated

3) la API REST contiene algunas cosas que no están disponibles en la API SOAP, incluyendo la API para chatter, y acceso a las listas de registros accedidos recientemente.

4) la API REST puede acceder a datos binarios (archivos, archivos adjuntos, contenido, etc.) sin la sobrecarga de la codificación/decodificación base64.

Por lo tanto, dependiendo de exactamente lo que intenta hacer su aplicación puede empujarlo de una forma u otra.

Answer 2

Creo que termina siendo una preferencia personal si la consume una aplicación .NET, independientemente de si es una aplicación web o no.

Personalmente, me gustaría ir con SOAP ya que .NET tiene una gran cantidad de funcionalidad incorporada para consumir un servicio SOAP, crea todos los prototipos de métodos para usted y hará que el desarrollo sea más rápido que usted mismo. .NET se ocupará de la clasificación de SOAP.

En cuanto a la construcción de una envoltura, usted tiene que considerar su público objetivo , si su público objetivo es más desarrolladores de aplicaciones .NET, a continuación, la exposición de su propio servicio de WCF podría ser una opción decente, WCF también tiene puntos finales para cualquiera de SOAP o REST.

Answer 3

La decisión de utilizar REST o SOAP cuando ambos están disponibles generalmente está relacionada con:

1. Las herramientas y el lenguaje que está utilizando para su aplicación
2. Su familiaridad con cualquiera de los estilos
3. El desempeño necesidades de su aplicación (cargas útiles JSON son más pequeñas que las cargas útiles XML)

Si las aplicaciones 'locales' están llamando a los servicios del lado del servidor, entonces todo lo demás igual, yo Puede al menos generar código C# directamente desde el WSDL y eso simplifica el uso de la API SOAP (sin codificación manual).

Si la aplicación web necesita llamar a la API directamente desde el lado del cliente (navegador), entonces use REST y trabaje con JSON. Esto será mucho más simple. No podría volver a utilizar el mismo contenedor independientemente, así que no hay problema con el uso de dos API distintas del tiempo que lleva aprenderlas.

Si el uso de la aplicación web de la API está en el lado del servidor (no del cliente), entonces apunte definitivamente a una sola API. WSDL si desea generar automáticamente el código para llamarlo, REST de lo contrario, por simplicidad y eficiencia.

Answer 4

IMO, SOAP fue un estándar creado como un tipo de contrato de arquitecto de mensajes, es decir. Cuando pasa mensajes solo use este "contrato". Era tan genérico que no abarca ninguna tecnología en particular.

REST es una metodología real que abarca HTTP, es una forma de utilizar GET, POST, PUT y DELETE a su máximo potencial.

No supongo que uno es mejor que el otro, lo que realmente se reduce a utilizar la herramienta adecuada para el trabajo. No haría una distinción entre aplicaciones basadas en web y no basadas en web. Porque SOAP o REST pueden ser beneficiosos para ambos.

Aquí hay algunas preguntas que me responderían primero:
1) ¿Quién es mi cliente de destino? Microsoft Workshop Client, Java, tipo PHP.
2) ¿Qué tipos de (La falta de un término mejor.) "Puntos finales" quiero exponer a mi Api. (JSON, XML, Ajax, POX o todo lo anterior.)
3) ¿Qué van a hacer mis clientes con esta API? ¿Ya tienen clientes basados ​​en SOAP? Si es así, SOAP es el camino a seguir.
4) REST le hará pensar en el diseño de su URL y, por lo tanto, le permitirá a un cliente "combinar" los datos para crear lo que necesita. Entonces, si piensas que es algo que quieres. REST es el camino a seguir.
5) REST hace uso de "GET" en HTTP, esto permite que un cliente almacene los resultados. "Conditional GET es lo que se llama. Les permite almacenar en caché un objeto grande, pregunte al servidor por un encabezado (pequeño) si la última actualización coincide con lo que se almacena en caché, de ser así. No se moleste con un objeto completo GET, qué se almacena en caché es la versión más reciente. esto se puede hacer de jabón, pero fuera de la caja, el resto es mejor para esto.

de todos modos, es de esperar que le brinda los mejores datos, para que pueda tomar la mejor decisión. Y si todo lo demás puede hacer ambas cosas, pero deberá tratar de obtener dos tipos de servicios (diferentes metodologías) y una base de código para ambos. (puede ser complicado, pero no tan difícil)

Personalmente, elegiría uno, y si alguna vez necesitas el otro, quema ese puente y paga la deuda técnica por ello.

Answer 5

En mi humilde opinión, si está desarrollando la solución de .NET como lo indica su pregunta, SOAP es el camino a seguir. Los servicios REST son beneficiosos porque carecen de los requisitos de conjunto y conjunto de herramientas que rodean a SOAP y son agradables para el desarrollador de bootstrap sin acceso a pesadas herramientas de inversión como .NET. Estoy de acuerdo con los otros comentarios de que REST refleja más de cerca la metodología HTTP subyacente, y es más fácil de leer y analizar explícitamente, pero eso no es realmente algo de lo que deba preocuparse dentro de una herramienta como VS y .NET.

Además, dado que tiene aplicaciones de consola existentes que pueden incorporarse a la combinación de comunicación en algún momento, sería bueno tener la flexibilidad de WCF para ser independiente del transporte y no vinculada a HTTP como lo sería con REST.

Así que realmente no creo que esté en condiciones de aprovechar las ventajas de REST o verse afectado por las deficiencias de SOAP, por lo que tiene sentido ir con la opción altamente estandarizada que mejor se adapta a su herramienta existente conjunto.

Answer 6

tarde a este partido, pero sólo una pequeña nota:

La API de Salesforce no es del todo REST: Yo diría que es REST-ish. Tiene consultas tipo SQL en URL para algunos de su interfaz REST, ese tipo de cosas.

Answer 7

de SOAP API:

¿Qué es? Integración de los datos de su organización con otras aplicaciones que usan SOAP.

¿Cuándo usarlo? Tiene servicios de middleware preexistentes que necesitan trabajar con WSDL y datos XML.

protocolo SOAP/WSDL formato datos XML comunicación sincrónica

REST API:

¿Qué es? Accediendo a objetos en su organización usando REST. ¿Cuándo usarlo? Desea aprovechar la arquitectura REST para integrarse con su organización. Sin requisito WSDL. Adecuado para aplicaciones basadas en navegador, aplicaciones móviles y aplicaciones sociales altamente interactivas. Protocolo REST Formato de datos JSON, XML Comunicación Sincrónica