web services - services - SOAP vs REST(diferencias)

web service rest (12)

Adición para:

++ Un error que a menudo se comete al acercarse a REST es pensar en él como "servicios web con URL": pensar en REST como otro mecanismo de llamada a procedimiento remoto (RPC), como SOAP, pero invocado a través de URL HTTP simples y sin el robusto SOAP. Espacios de nombres XML

++ Por el contrario, REST tiene poco que ver con RPC. Mientras que RPC está orientado al servicio y enfocado en acciones y verbos, REST está orientado a los recursos, enfatizando las cosas y los sustantivos que forman una aplicación.

He leído artículos sobre las diferencias entre SOAP y REST como protocolo de comunicación de servicio web, pero creo que las mayores ventajas para REST sobre SOAP son:

REST es más dinámico, no es necesario crear y actualizar UDDI.
REST no está restringido al formato XML. Los servicios web REST pueden enviar texto sin formato, JSON y también XML.

Pero SOAP está más estandarizado (Ex; seguridad).

Entonces, ¿estoy en lo cierto en estos puntos?

Desafortunadamente, hay mucha información errónea y conceptos erróneos en torno a REST. No solo su pregunta y la respuesta de @cmd reflejan esas, sino que la mayoría de las preguntas y respuestas relacionadas con el tema en .

SOAP y REST no se pueden comparar directamente, ya que el primero es un protocolo (o al menos intenta serlo) y el segundo es un estilo arquitectónico. Esta es probablemente una de las fuentes de confusión que la rodea, ya que las personas tienden a llamar REST a cualquier API HTTP que no sea SOAP.

Empujando un poco las cosas e intentando establecer una comparación, la principal diferencia entre SOAP y REST es el grado de acoplamiento entre las implementaciones de cliente y servidor. Un cliente SOAP funciona como una aplicación de escritorio personalizada, estrechamente unida al servidor. Hay un contrato rígido entre el cliente y el servidor, y se espera que todo se rompa si cualquiera de las partes cambia algo. Necesita actualizaciones constantes después de cualquier cambio, pero es más fácil determinar si el contrato se está cumpliendo.

Un cliente REST es más como un navegador. Es un cliente genérico que sabe cómo usar un protocolo y métodos estandarizados, y una aplicación tiene que caber dentro de eso. No viola los estándares de protocolo al crear métodos adicionales, aprovecha los métodos estándar y crea las acciones con ellos en su tipo de medio. Si se hace correctamente, hay menos acoplamiento, y los cambios se pueden tratar con más gracia. Se supone que un cliente ingresa a un servicio REST sin conocimiento de la API, excepto el punto de entrada y el tipo de medio. En SOAP, el cliente necesita conocimientos previos sobre todo lo que usará, o ni siquiera comenzará la interacción. Además, un cliente REST puede ampliarse mediante el código a pedido suministrado por el propio servidor, el ejemplo clásico es el código JavaScript utilizado para impulsar la interacción con otro servicio en el lado del cliente.

Creo que estos son los puntos cruciales para entender de qué se trata REST y en qué se diferencia de SOAP:

REST es un protocolo independiente. No está acoplado a HTTP. Al igual que puede seguir un enlace ftp en un sitio web, una aplicación REST puede usar cualquier protocolo para el que exista un esquema de URI estandarizado.
REST no es una asignación de CRUD a métodos HTTP. Lea this respuesta para una explicación detallada sobre eso.
REST está tan estandarizado como las piezas que está utilizando. La seguridad y la autenticación en HTTP están estandarizadas, así que eso es lo que usa cuando hace REST a través de HTTP.
REST no es REST sin hypermedia y HATEOAS . Esto significa que un cliente solo conoce el URI del punto de entrada y se supone que los recursos deben devolver los enlaces que el cliente debe seguir. Esos generadores de documentación de lujo que dan patrones de URI para todo lo que puede hacer en una API REST pierden el punto por completo. No solo están documentando algo que se supone que debe seguir el estándar, sino que, al hacerlo, están vinculando al cliente con un momento particular en la evolución de la API, y cualquier cambio en la API debe documentarse y aplicarse. o se romperá.
REST es el estilo arquitectónico de la propia web. Cuando ingresa al Desbordamiento de pila, sabe qué es un usuario, una pregunta y una respuesta, conoce los tipos de medios y el sitio web le proporciona los enlaces a ellos. Una API REST tiene que hacer lo mismo. Si diseñamos la web de la forma en que la gente piensa que se debe hacer REST, en lugar de tener una página de inicio con enlaces a Preguntas y Respuestas, tendríamos una documentación estática que explica que para ver una pregunta, debe tomar el URI .com/questions/<id> , reemplace id con Question.id y péguelo en su navegador. Eso es una tontería, pero eso es lo que mucha gente piensa que REST es.

Este último punto no se puede enfatizar lo suficiente. Si sus clientes están creando URI a partir de plantillas en la documentación y no obtienen enlaces en las representaciones de recursos, eso no es REST. Roy Fielding, el autor de REST, dejó claro en esta publicación del blog: las API de REST deben ser controladas por hipertexto .

Teniendo en cuenta lo anterior, te darás cuenta de que si bien REST no está restringido a XML, para hacerlo correctamente con cualquier otro formato, tendrás que diseñar y estandarizar algún formato para tus enlaces. Los hipervínculos son estándar en XML, pero no en JSON. Hay proyectos de normas para JSON, como HAL .

Finalmente, REST no es para todos, y una prueba de ello es cómo la mayoría de las personas resuelven sus problemas muy bien con las API HTTP que denominaron REST por error y nunca se aventuran más allá de eso. REST es difícil de hacer a veces, especialmente al principio, pero paga con el tiempo con una evolución más sencilla en el lado del servidor y la resistencia del cliente a los cambios. Si necesita que se haga algo rápida y fácilmente, no se moleste en obtener el RESTO correctamente. Probablemente no es lo que estás buscando. Si necesita algo que tendrá que permanecer en línea durante años o incluso décadas, entonces REST es para usted.

Diferencia entre descanso y jabón.

JABÓN

SOAP es un protocolo.
SOAP significa protocolo simple de acceso a objetos.
SOAP no puede usar REST porque es un protocolo.
SOAP utiliza interfaces de servicios para exponer la lógica de negocios.
SOAP define estándares a seguir estrictamente.
SOAP requiere más ancho de banda y recursos que REST.
SOAP define su propia seguridad.
SOAP solo permite el formato de datos XML.
SOAP es menos preferido que REST.

DESCANSO

REST es un estilo arquitectónico.
REST significa Representational State Transfer.
REST puede usar los servicios web SOAP porque es un concepto y puede usar cualquier protocolo como HTTP, SOAP.
REST utiliza URI para exponer la lógica empresarial.
REST no define demasiados estándares como SOAP.
REST requiere menos ancho de banda y recursos que SOAP.
Los servicios web RESTful heredan medidas de seguridad del transporte subyacente.
REST permite diferentes formatos de datos, como texto sin formato, HTML, XML, JSON, etc.
REST más preferido que el jabón.

Para más detalles por favor vea here

En mi humilde opinión no puedes comparar SOAP y REST donde esas son dos cosas diferentes.

SOAP es un protocolo y REST es un patrón arquitectónico de software. Hay una gran cantidad de conceptos erróneos en Internet para SOAP vs REST .

SOAP define el formato de mensaje basado en XML que las aplicaciones habilitadas para el servicio web utilizan para comunicarse entre sí a través de Internet. Para hacer eso, las aplicaciones necesitan un conocimiento previo del contrato del mensaje, tipos de datos, etc.

REST representa el estado (como recursos) de un servidor desde una URL. Es sin estado y los clientes no deben tener conocimientos previos para interactuar con el servidor más allá de la comprensión de hipermedia.

En primer lugar: en el sentido vago, servicio web significa usar el protocolo HTTP para transferir datos en lugar de páginas web. Sin embargo, en el sentido estricto , un servicio web, tal como lo define W3C, es una forma muy específica de esa idea. Entonces, cuando las personas hablan de SOAP vs. REST , en realidad se refieren a servicios web vs. REST (donde "servicios web" se refiere a la definición oficial, ya que, en la práctica, los servicios REST también son llamados servicios web por todos).

Entonces, digamos que desea llamar a una función en una computadora remota, implementada en algún otro lenguaje de programación ( llamada a procedimiento remoto / RPC ). Tienes que (de alguna manera) enviar un mensaje y obtener alguna respuesta. Primero, esa función se puede encontrar en una URL específica, proporcionada por su creador. Entonces, hay dos preguntas principales a considerar.

¿Cuál es el formato del mensaje que debe enviar?
¿Cómo se debe llevar el mensaje de un lado a otro?

Según la definición oficial, la respuesta a la primera pregunta es el WSDL , un XML que describe, en formato detallado y estricto, cuáles son los parámetros, cuáles son sus tipos, nombres, valores predeterminados, el nombre de la función a llamar. , etc. A la segunda pregunta, hay varias respuestas. El más popular (por mucho) es el SOAP . Su idea principal es: envolver el XML anterior (el mensaje real) en otro XML más, y enviarlo a través de HTTP (aunque, en teoría, se puede usar con otros protocolos, pero nadie lo hace). El método POST de HTTP se utiliza para enviar el mensaje, ya que siempre hay un cuerpo.

Entonces, según el enfoque (ampliamente, pero erróneamente) llamado SOAP, asignas una URL a una función, eso es una acción . El enfoque RESTful es: en lugar de que la URL represente una acción, debe representar una cosa (llamada recurso en la jerga RESTful). Dado que el protocolo HTTP (que ya estamos usando) es compatible con verbos, use esos verbos para especificar qué acciones realizar en la cosa.

Entonces, con el enfoque SOAP (de nuevo, término incorrecto), si tiene una lista de clientes y desea ver / actualizar / eliminar uno, tendrá 3 URLS:

myapp/read-customer y en el cuerpo del mensaje, pase la identificación del cliente a leer.
myapp/update-customer y en el cuerpo, pase la identificación del cliente, así como los nuevos datos
myapp/delete-customer y el id en el cuerpo

Mientras, con el enfoque REST, solo tendría myapp/customers/3 (donde 3 es el id de un cliente específico). Para ver los datos del cliente, puede acceder a la URL con una solicitud GET. Para borrarlo, la misma URL, con un verbo DELETE. Para actualizarlo, nuevamente, la misma URL con un verbo POST y el nuevo contenido en el cuerpo de la solicitud.

Para obtener más detalles sobre los requisitos que debe cumplir un servicio para que se considere realmente RESTful, consulte el modelo de madurez de Richardson . El artículo da ejemplos y, lo que es más importante, explica por qué un servicio SOAP (llamado) es un servicio REST de nivel 0 (aunque, nivel 0 significa un bajo cumplimiento de este modelo, no es ofensivo y aún es útil en muchos casos).

Entre las muchas respuestas que ya se cubrieron en las muchas respuestas, destacaría que SOAP permite definir un contrato, el WSDL, que define las operaciones admitidas, los tipos complejos, etc. SOAP está orientado a las operaciones, pero REST está orientado a los recursos. Personalmente, seleccionaría SOAP para interfaces complejas entre aplicaciones empresariales internas y REST para interfaces públicas, más simples y sin estado con el mundo exterior.

La decisión entre los dos será su primera opción para diseñar un servicio web, por lo que es importante comprender los pros y los contras de los dos. También es importante, en el acalorado debate entre las dos filosofías, separar la realidad de la retórica.

Fundamentos de descanso

Todo en REST es considerado como un recurso.
Cada recurso es identificado por un URI.
Utiliza interfaces uniformes. Los recursos se manejan mediante las operaciones POST, GET, PUT, DELETE que son similares a las operaciones Crear, Leer, Actualizar y Eliminar (CRUD).
Se apátrida Cada solicitud es una solicitud independiente. Cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud.
Las comunicaciones se realizan a través de representaciones. Por ejemplo, XML, JSON RESTful Web Services. Los servicios web RESTful se basan en métodos HTTP y el concepto de REST. Un servicio web RESTful generalmente define el URI base para los servicios; los tipos MIME admitidos (XML, texto, JSON, definidos por el usuario, ...) y el conjunto de operaciones (POST, GET, PUT, DELETE) que son compatibles.

Fundamentos de jabón

WSDL define el contrato entre el cliente y el servicio y es estático por su naturaleza.
SOAP construye un protocolo basado en XML sobre HTTP o, a veces, TCP / IP.
SOAP describe funciones y tipos de datos.
SOAP es un sucesor de XML-RPC y es muy similar, pero describe una forma estándar de comunicación.
Varios lenguajes de programación tienen soporte nativo para SOAP, normalmente alimenta una URL de servicio web y puede llamar a sus funciones de servicio web sin la necesidad de un código específico.
Los datos binarios que se envían deben codificarse primero en un formato como el codificado en base64.
Tiene varios protocolos y tecnologías relacionadas con él: WSDL, XSD, SOAP, WS-Addressing.

¿SOAP vs REST?

Uno de los principales beneficios de SOAP es que tiene una descripción de servicio WSDL. Puede descubrir el servicio automáticamente y generar un proxy de cliente utilizable a partir de esa descripción del servicio (generar las llamadas de servicio, los tipos de datos necesarios para los métodos, etc.). Tenga en cuenta que con la versión 2.0, WSDL es compatible con todos los verbos HTTP y también se puede usar para documentar los servicios RESTful, pero existe una alternativa menos detallada en WADL (Lenguaje de descripción de aplicaciones web) para ese propósito.

Con los servicios REST, la seguridad de los mensajes es proporcionada por el protocolo de transporte (HTTPS) y es solo punto a punto. No tiene un sistema de mensajería estándar y espera que los clientes resuelvan las fallas de comunicación al reintentar. SOAP tiene una lógica exitosa / de reintento incorporada y proporciona confiabilidad de extremo a extremo incluso a través de intermediarios SOAP.

Uno de los principales beneficios de RESTful API es que es flexible para la representación de datos, por ejemplo, podría serializar sus datos en formato XML o JSON. Las API RESTful son más limpias o fáciles de entender porque agregan un elemento de uso de URI estandarizadas y le dan importancia al verbo HTTP utilizado (es decir, GET, POST, PUT y DELETE).

Los servicios RESTful también son ligeros, es decir, no tienen una gran cantidad de marcado XML adicional. Para invocar la API RESTful, todo lo que necesita es un navegador o una pila HTTP y casi todos los dispositivos o máquinas conectados a una red tienen eso.

Ventajas de REST

Dado que REST utiliza HTTP estándar, es mucho más simple en casi todos los aspectos. Crear clientes, desarrollar API, la documentación es mucho más fácil de entender, y no hay muchas cosas que REST no haga más fácil / mejor que SOAP.
REST permite muchos formatos de datos diferentes, mientras que SOAP solo permite XML. Si bien esto puede parecer que agrega complejidad a REST porque necesita manejar múltiples formatos, en mi experiencia, ha sido bastante beneficioso. JSON por lo general es un mejor ajuste para los datos y analiza mucho más rápido. REST permite un mejor soporte para los clientes del navegador debido a su soporte para JSON.
REST tiene mejor rendimiento y escalabilidad. Las lecturas REST se pueden almacenar en caché; Las lecturas basadas en SOAP no se pueden almacenar en caché.
Ninguna herramienta costosa requiere interactuar con el servicio web
Curva de aprendizaje más pequeña
Eficiente (SOAP usa XML para todos los mensajes, REST puede usar formatos de mensajes más pequeños)
Rápido (no requiere procesamiento extenso)
Más cerca de otras tecnologías web en la filosofía del diseño.

Ventajas del jabón

WS-Security: si bien SOAP admite SSL (al igual que REST), también es compatible con WS-Security, que agrega algunas características de seguridad empresarial. Admite la identidad a través de intermediarios, no solo punto a punto (SSL). También proporciona una implementación estándar de integridad de datos y privacidad de datos. Llamarlo "empresa" no significa que sea más seguro, simplemente es compatible con algunas herramientas de seguridad que los servicios de Internet típicos no necesitan, de hecho, solo se necesitan en algunos escenarios "empresariales".
WS-AtomicTransaction: necesita transacciones ACID sobre un servicio, usted necesitará SOAP. Si bien REST admite transacciones, no es tan completo y no cumple con ACID. Afortunadamente, las transacciones de ACID casi nunca tienen sentido en Internet. La REST está limitada por el propio HTTP, que no puede proporcionar una confirmación en dos fases a través de recursos transaccionales distribuidos, pero SOAP sí puede. Las aplicaciones de Internet no necesitan este nivel de confiabilidad transaccional, las aplicaciones empresariales a veces sí.
WS-ReliableMessaging: Rest no tiene un sistema de mensajería estándar y espera que los clientes resuelvan las fallas de comunicación al reintentar. SOAP tiene una lógica exitosa / de reintento incorporada y proporciona confiabilidad de extremo a extremo incluso a través de intermediarios SOAP.
Idioma, plataforma y transporte independientes (REST requiere el uso de HTTP)
Funciona bien en entornos empresariales distribuidos (REST asume la comunicación directa punto a punto)
Estandarizado
Proporciona una amplia extensibilidad previa a la construcción en forma de los estándares de WS
Manejo de errores incorporado
Automatización cuando se utiliza con ciertos productos lingüísticos.

Donde usar REST

Las áreas donde REST funciona bien son:

Ancho de banda y recursos limitados: recuerde que la estructura de retorno está realmente en cualquier formato (definido por el desarrollador). Además, se puede usar cualquier navegador porque el enfoque REST usa los verbos estándar GET, PUT, POST y DELETE. Nuevamente, recuerde que REST también puede usar el objeto XMLHttpRequest que la mayoría de los navegadores modernos soportan hoy en día, lo que agrega un bono de AJAX.
Operaciones sin estado: si una operación necesita continuar, REST no es el mejor enfoque y SOAP puede ajustarse mejor. Sin embargo, si necesita operaciones CRUD (Crear, Leer, Actualizar y Eliminar) sin estado, entonces REST lo es.
Situaciones de almacenamiento en caché: si la información se puede almacenar en caché debido a la operación sin estado del enfoque REST, esto es perfecto.

Donde usar el jabón

Áreas donde SOAP funciona como una gran solución:

Procesamiento e invocación asíncronos: si su aplicación necesita un nivel garantizado de confiabilidad y seguridad, SOAP 1.2 ofrece estándares adicionales para garantizar este tipo de operación. Cosas como WSRM - WS-Reliable Messaging.
Contratos formales: si ambas partes (proveedor y consumidor) tienen que acordar el formato de intercambio, SOAP 1.2 proporciona las especificaciones rígidas para este tipo de interacción.
Operaciones con estado: si la aplicación necesita información contextual y administración del estado conversacional, SOAP 1.2 tiene la especificación adicional en la estructura de WS para respaldar esas cosas (Seguridad, Transacciones, Coordinación, etc.). Comparativamente, el enfoque REST haría que los desarrolladores construyeran esta plomería personalizada.

Muchas de estas respuestas olvidaron por completo mencionar los controles de hipermedia (HATEOAS) que son completamente fundamentales para REST. Algunos otros lo tocaron, pero en realidad no lo explicaron tan bien.

Este artículo debe explicar la diferencia entre los conceptos, sin entrar en las malezas en características de SOAP específicas.

SOAP ( Protocolo de acceso a objetos simples ) y REST ( Representación de transferencia de estado ) son hermosos a su manera. Así que no los estoy comparando. En su lugar, estoy tratando de representar la imagen, cuando prefiero usar REST y cuando SOAP.

¿Qué es la carga útil?

Cuando los datos se envían a través de Internet, cada unidad transmitida incluye tanto la información del encabezado como los datos reales que se envían. El encabezado identifica el origen y el destino del paquete, mientras que los datos reales se conocen como la carga útil . En general, la carga útil es la información que se transporta en nombre de una aplicación y la información recibida por el sistema de destino.

Ahora, por ejemplo, tengo que enviar un telegrama y todos sabemos que el costo del telegrama dependerá de algunas palabras.

Entonces, dime, entre los siguientes mensajes mencionados, ¿cuál es más barato de enviar?

<name>Arin</name>

"name": "Arin"

Sé que su respuesta será la segunda, aunque las dos que representan el mismo mensaje segundo es más económica en cuanto al costo.

Así que estoy tratando de decir que enviar datos a través de la red en formato JSON es más barato que enviarlos en formato XML con respecto a la carga útil .

Aquí está el primer beneficio o ventajas de REST sobre SOAP . SOAP solo admite XML, pero REST admite diferentes formatos como texto, JSON, XML, etc. Y ya lo sabemos, si usamos Json entonces definitivamente estaremos en un mejor lugar con respecto a la carga útil.

Ahora, SOAP es compatible con el único XML, pero también tiene sus ventajas.

¡De Verdad! ¿Cómo?

SOAP se basa en XML de tres formas Envelope: que define qué hay en el mensaje y cómo procesarlo.

Un conjunto de reglas de codificación para los tipos de datos y, finalmente, el diseño de las llamadas a los procedimientos y las respuestas recopiladas.

Este sobre se envía a través de un transporte (HTTP / HTTPS) y se ejecuta una RPC (Llamada a procedimiento remoto), y el sobre se devuelve con la información en un documento con formato XML.

El punto importante es que una de las ventajas de SOAP es el uso del transporte "genérico", pero REST utiliza HTTP / HTTPS . SOAP puede usar casi cualquier transporte para enviar la solicitud, pero REST no puede. Así que aquí tenemos la ventaja de usar SOAP.

Como ya mencioné en el párrafo anterior "REST usa HTTP / HTTPS" , así que profundice un poco más en estas palabras.

Cuando hablamos de REST a través de HTTP, todas las medidas de seguridad que se aplican a HTTP se heredan, y esto se conoce como seguridad a nivel de transporte y protege los mensajes solo mientras está dentro del cable, pero una vez que lo entregó en el otro lado, no lo sabe. Cuántas etapas tendrá que pasar antes de llegar al punto real donde se procesarán los datos. Y, por supuesto, todas esas etapas podrían usar algo diferente a HTTP. Así que el descanso no es completamente seguro, ¿verdad?

Pero SOAP admite SSL al igual que REST, además , también es compatible con WS-Security, que agrega algunas características de seguridad empresarial. WS-Security ofrece protección desde la creación del mensaje hasta su consumo . Por lo tanto, para la seguridad a nivel de transporte, cualquier laguna legal que encontremos se puede evitar utilizando WS-Security.

Además, como REST está limitado por su protocolo HTTP, su soporte de transacciones no es compatible con ACID ni puede proporcionar un compromiso en dos fases a través de recursos transnacionales distribuidos.

Pero SOAP tiene un soporte integral tanto para la gestión de transacciones basada en ACID para transacciones de corta duración como para la gestión de transacciones basada en compensación para transacciones de larga duración. También es compatible con la confirmación de dos fases a través de recursos distribuidos .

No estoy llegando a ninguna conclusión, pero preferiré un servicio web basado en SOAP mientras que la seguridad, la transacción, etc. sean las principales preocupaciones.

Aquí está el "Tutorial de Java EE 6" donde dicen que un diseño RESTful puede ser apropiado cuando se cumplen las siguientes condiciones . Echar un vistazo.

Espero que hayas disfrutado leyendo mi respuesta.

SOAP es un protocolo mientras que REST es arquitectura.
SOAP expone el comportamiento que representa la lógica, mientras que REST expone los recursos que representan datos.
En términos de consumo, el servicio REST es mucho más simple que SOAP. Con REST, se elimina la sobrecarga de manejo de envolventes XML, lo que lo hace más rápido en comparación con SOAP.
SOAP proporcionó buenas opciones de seguridad en comparación con REST.
Para la interacción de máquina a máquina y las soluciones empresariales, es preferible utilizar SOAP, pero para la API pública, REST es la mejor opción, casi el 70% de las API públicas son REST.
REST es ligero, fácil de mantener y escalable.
REST es independiente del dispositivo, es decir, la API REST que consume el cliente puede ser cualquier cosa como dispositivos móviles, portátiles, TV, etc.
Con la nube entrando en acción. La aplicación se está moviendo lentamente a sistemas basados en la nube como Azure, Amazon AWS. Estos sistemas están construyendo y exponiendo las API REST. Por lo tanto, es un buen paso para construir una aplicación en la parte superior de la API REST.

REST vs SOAP

REST vs SOAP no es la pregunta correcta.

REST , a diferencia de SOAP no es un protocolo.

REST es un estilo arquitectónico y un diseño para arquitecturas de software basadas en red.

REST conceptos REST se denominan recursos. Una representación de un recurso debe ser apátrida. Se representa a través de algún tipo de medio. Algunos ejemplos de tipos de medios incluyen XML , JSON y RDF . Los recursos son manipulados por componentes. Los componentes solicitan y manipulan recursos a través de una interfaz uniforme estándar. En el caso de HTTP, esta interfaz consiste en operaciones HTTP estándar, por ejemplo, GET , PUT , POST , DELETE .

La pregunta de @ Abdulaziz ilumina el hecho de que REST y HTTP se usan a menudo en tándem. Esto se debe principalmente a la simplicidad de HTTP y su mapeo muy natural a los principios REST.

Principios fundamentales de REST

Comunicación cliente-servidor

Las arquitecturas cliente-servidor tienen una separación de preocupaciones muy distinta. Todas las aplicaciones creadas en el estilo RESTful también deben ser cliente-servidor en principio.

Apátrida

Cada solicitud de cliente al servidor requiere que su estado esté completamente representado. El servidor debe poder comprender completamente la solicitud del cliente sin utilizar ningún contexto de servidor o estado de sesión del servidor. De ello se deduce que todo estado debe mantenerse en el cliente.

Cacheable

Se pueden usar restricciones de caché, permitiendo así que los datos de respuesta se marquen como cacheables o no cacheables. Cualquier dato marcado como almacenable en caché puede reutilizarse como respuesta a la misma solicitud posterior.

Interfaz uniforme

Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que toda la interacción de componentes ocurre a través de esta interfaz, la interacción con diferentes servicios es muy simple. La interfaz es la misma! Esto también significa que los cambios de implementación se pueden hacer de forma aislada. Dichos cambios no afectarán la interacción de los componentes fundamentales porque la interfaz uniforme siempre se mantiene sin cambios. Una desventaja es que estás atascado con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. En el lado positivo, sin embargo, REST está optimizado para la web, por lo tanto, ¡una popularidad increíble de REST a través de HTTP!

Los conceptos anteriores representan las características definitorias de REST y diferencian la arquitectura REST de otras arquitecturas como los servicios web. Es útil tener en cuenta que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.

Consulte esta publicación de blog sobre los Principios de diseño de REST para obtener más detalles sobre REST y las viñetas indicadas anteriormente.

EDITAR: actualizar el contenido basado en comentarios

REST ( RE presentación del estado T ransfer)
REST es un estilo arquitectónico. No define tantos estándares como SOAP. REST es para exponer las API públicas (es decir, la API de Facebook, la API de Google Maps) a través de Internet para manejar las operaciones de CRUD en los datos. REST se enfoca en acceder a recursos nombrados a través de una única interfaz consistente.

JABÓN ( S imple O bject A ccess P rotocol)
SOAP trae su propio protocolo y se enfoca en exponer partes de la lógica de la aplicación (no datos) como servicios. SOAP expone operaciones. SOAP se enfoca en acceder a operaciones con nombre, cada operación implementa alguna lógica de negocios. Aunque a SOAP se le conoce comúnmente como servicios web, esto es incorrecto. SOAP tiene muy poco o nada que ver con la web. REST proporciona verdaderos servicios web basados en URI y HTTP.

¿Por qué REST?

Dado que REST utiliza HTTP estándar, es mucho más simple en casi todos los casos.
REST es más fácil de implementar, requiere menos ancho de banda y recursos.
REST permite muchos formatos de datos diferentes, mientras que SOAP solo permite XML.
REST permite un mejor soporte para los clientes del navegador debido a su soporte para JSON.
REST tiene mejor rendimiento y escalabilidad. Las lecturas REST pueden almacenarse en caché, las lecturas basadas en SOAP no pueden almacenarse en caché.
Si la seguridad no es una preocupación importante y tenemos recursos limitados. O queremos crear una API que otros desarrolladores puedan utilizar públicamente y luego deberíamos utilizar REST.
Si necesitamos operaciones CRUD sin estado, vaya con REST.
REST se usa comúnmente en redes sociales, chat web, servicios móviles y API públicas como Google Maps.
El servicio RESTful devuelve varios MediaTypes para el mismo recurso, dependiendo del parámetro del encabezado de solicitud "Aceptar" como application/xml o application/json para POST y /user/1234.json o GET /user/1234.xml para GET.
Los servicios REST están destinados a ser llamados por la aplicación del lado del cliente y no directamente por el usuario final.
ST en REST proviene del estado T ransfer. Si transfiere el estado en lugar de que el servidor lo almacene, esto hace que los servicios REST sean escalables.

¿Por qué jabón?

SOAP no es muy fácil de implementar y requiere más ancho de banda y recursos.
La solicitud de mensaje SOAP se procesa de forma más lenta en comparación con REST y no utiliza el mecanismo de almacenamiento en caché web.
WS-Security: si bien SOAP admite SSL (al igual que REST), también es compatible con WS-Security, que agrega algunas características de seguridad empresarial.
WS-AtomicTransaction: necesita transacciones ACID sobre un servicio, usted necesitará SOAP.
WS-ReliableMessaging: si su aplicación necesita un procesamiento asíncrono y un nivel garantizado de confiabilidad y seguridad. Rest no tiene un sistema de mensajería estándar y espera que los clientes resuelvan las fallas de comunicación al reintentar.
Si la seguridad es una preocupación importante y los recursos no están limitados, entonces deberíamos usar los servicios web SOAP. Al igual que si estamos creando un servicio web para pasarelas de pago, trabajos relacionados con las finanzas y las telecomunicaciones, deberíamos utilizar SOAP, ya que aquí se necesita alta seguridad.

spf13.com/post/soap-vs-rest
source2