¿Debería un servicio web de estilo Netflix o Twitter usar REST o SOAP? [cerrado]

He implementado dos servicios REST: Twitter y Netflix. En ambas ocasiones, luché por encontrar el uso y la lógica involucrados en la decisión de exponer estos servicios como REST en lugar de SOAP. Espero que alguien pueda darme una idea de lo que me falta y explicar por qué REST se utilizó como implementación de servicios para servicios como estos.

1. La implementación de un servicio REST lleva infinitamente más tiempo que la implementación de un servicio SOAP. Existen herramientas para todos los lenguajes / frameworks / plataformas modernos para leer en un WSDL y generar clases proxy y clientes. La implementación de un servicio REST se realiza a mano y, consiga esto, leyendo la documentación. Además, al implementar estos dos servicios, debe hacer "conjeturas" sobre lo que volverá a aparecer a través de la tubería ya que no existe un esquema real o documento de referencia.

2. ¿Por qué escribir un servicio REST que devuelve XML de todos modos? La única diferencia es que con REST no conoce los tipos que representa cada elemento / atributo: está solo para implementarlo y espera que algún día no se encuentre una cadena en un campo que pensó que siempre era un int. SOAP define la estructura de datos utilizando el WSDL, por lo que es obvio.

3. He escuchado la queja de que con SOAP tienes la "sobrecarga" del SOAP Envelope. En la actualidad, ¿realmente debemos preocuparnos por un puñado de bytes?

4. He escuchado el argumento de que con REST puede simplemente abrir la URL en el navegador y ver los datos. Claro, si su servicio REST está utilizando autenticación simple o no. El servicio de Netflix, por ejemplo, utiliza OAuth, que requiere que firmes y codifiques cosas antes de que puedas enviar tu solicitud.

5. ¿Por qué necesitamos una URL "legible" para cada recurso? Si estuviéramos usando una herramienta para implementar el servicio, ¿realmente nos importa la URL real?

Un canario en una mina de carbón.

Llevo casi un año esperando una pregunta como esta. Era inevitable que este día llegara y estoy seguro de que veremos muchas más preguntas como esta en los próximos meses.

Las señales de advertencia

Tiene toda la razón, lleva más tiempo construir clientes RESTful que clientes SOAP. Los kits de herramientas SOAP eliminan gran cantidad de código repetitivo y hacen que los objetos proxy del cliente estén disponibles casi sin esfuerzo. Con una herramienta como Visual Studio y una URL de servidor, puedo acceder a objetos remotos de complejidad arbitraria, localmente en menos de cinco minutos.

Los servicios que devuelven application / xml y application / json son muy molestos para los desarrolladores de clientes. ¿Qué se supone que debemos hacer con ese conjunto de datos?

Afortunadamente, muchos sitios que ofrecen servicios REST también proporcionan un montón de bibliotecas de clientes para que podamos usar esas bibliotecas para obtener acceso a un montón de objetos fuertemente tipados. Aunque parece un poco tonto. Si hubieran usado SOAP, podríamos haber codificado esas clases proxy por nosotros mismos.

JABÓN por encima, ja. Es la latencia lo que mata. Si la gente está realmente preocupada por la cantidad de bytes en exceso que atraviesan el cable, entonces quizás HTTP no sea la opción correcta. ¿Has visto cuántos bytes utiliza el encabezado de agente de usuario?

Sí, ¿alguna vez has intentado usar un navegador web como herramienta de depuración para cualquier cosa que no sea HTML y JavaScript? Confía en mí, es una mierda. Solo puede usar dos de los verbos, el almacenamiento en caché se interpone constantemente, el manejo de errores traga tanta información, está constantemente buscando un maldito favicon.ico. Sólo disparame.

URL legible. Solo sustantivos, no verbos. Sí, eso es fácil siempre que solo hagamos operaciones CRUD y solo necesitemos acceder a una jerarquía de objetos de una manera. Desafortunadamente, la mayoría de las aplicaciones necesitan un poco más de funcionalidad que eso.

El desastre inminente

Hay una carga métrica de desarrolladores que actualmente desarrollan aplicaciones que se integran con los servicios REST que están en el proceso de llegar al mismo conjunto de conclusiones que usted tiene. Se les prometió simplicidad, flexibilidad, escalabilidad, capacidad de evolución y el santo grial de la reutilización fortuita. Las características de la web en sí, cómo pueden salir mal las cosas.

Sin embargo, están descubriendo que el control de versiones es un problema, pero el compilador no ayuda a detectar problemas. El código del cliente escrito a mano es difícil de mantener a medida que las estructuras de datos evolucionan y las URL se refactorizan. Diseñar APIs alrededor de sustantivos y cuatro verbos puede ser realmente difícil, especialmente cuando los fanáticos de la URL RESTful te dicen cuándo puedes y no puedes usar cadenas de consulta.

Los desarrolladores comenzarán a preguntarse por qué estamos desperdiciando nuestro esfuerzo en admitir los formatos Json y Xml, ¿por qué no centramos nuestros esfuerzos en uno y lo hacemos bien?

¿Cómo salieron las cosas tan mal?

Te diré lo que salió mal. Como desarrolladores, dejamos que los departamentos de marketing aprovechen nuestra debilidad principal. Nuestra eterna búsqueda de la bala de plata nos cegó a la realidad de lo que realmente es REST. En la superficie, REST parece tan fácil y simple. Nombra tus recursos con Urls y usa GET, PUT, POST y DELETE. Demonios, los desarrolladores ya sabemos cómo hacerlo, hemos estado tratando con bases de datos durante años que tienen tablas y columnas y declaraciones SQL que tienen SELECT, INSERT, UPDATE y DELETE. Debería haber sido pan comido.

Hay otras partes de REST que algunas personas discuten, como la autodescripción y la restricción hipermedia, pero estas restricciones no son tan simples como la identificación de recursos y la interfaz uniforme. Parece agregar complejidad donde el objetivo deseado es la simplicidad.

Esta versión diluida de REST se validó en la cultura del desarrollador de muchas maneras. Se crearon marcos de servidores que fomentaron la identificación de recursos y la interfaz uniforme, pero no hicieron nada para soportar las otras restricciones. Los términos comenzaron a flotar alrededor de diferenciar los enfoques (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

Algunas personas gritan que si no aplica todas las restricciones no es REST. No obtendrá los beneficios. No hay medio descanso. Pero esas voces fueron etiquetadas como fanáticos religiosos que estaban molestos porque su precioso término había sido robado de la oscuridad y se había generalizado. Las personas celosas que intentan hacer que REST suene más difícil de lo que es.

REST, el término, definitivamente se ha convertido en la corriente principal. Casi todas las principales propiedades web que tienen una API admiten "REST". Twitter y Netflix son dos de muy alto perfil. Lo aterrador es que solo puedo pensar en una API pública que se autodescriba y hay algunas que realmente implementan la restricción hipermedia. Seguro que algunos sitios como StackOverflow y Gowalla admiten enlaces en sus respuestas, pero hay enormes agujeros en sus enlaces. La API StackOverflow no tiene página raíz. ¡Imagínese cuán exitoso hubiera sido el sitio web si no hubiera una página de inicio para el sitio web!

Te engañaste, me temo

Si ha llegado hasta aquí, la respuesta breve a su pregunta es que las API (Netflix y Twitter) no se ajustan a todas las restricciones y, por lo tanto, no obtendrá los beneficios que se supone que deben traer las API REST.

Los clientes REST tardan más en compilarse que los clientes SOAP, pero no están vinculados a un servicio específico, por lo que debería poder reutilizarlos en todos los servicios. Tomemos el ejemplo clásico de un navegador web. ¿A cuántos servicios puede acceder un navegador web? ¿Qué pasa con un lector de feeds? Ahora, ¿a cuántos servicios diferentes puede acceder el cliente promedio de Twitter? Si, solo uno.

Se supone que los clientes REST no están diseñados para interactuar con un solo servicio, sino que están diseñados para manejar tipos de medios específicos que podrían ser servidos por cualquier servicio. La pregunta obvia es: ¿cómo puede construir un cliente REST para un servicio que ofrece application / json o application / xml? Pues no puedes. Eso es porque esos formatos son completamente inútiles para un cliente REST. Tú mismo lo dijiste

tiene que hacer "conjeturas" sobre lo que volverá a aparecer a través de la tubería ya que no hay un esquema real o documento de referencia

Tiene toda la razón en servicios como Twitter. Sin embargo, la restricción autodescriptiva en REST dice que el encabezado del tipo de contenido HTTP debe describir exactamente el contenido que se transmite a través del cable. La entrega de application / json y application / xml no le dice nada sobre el contenido.

Cuando se trata de considerar el rendimiento de los sistemas basados ​​en REST, es necesario observar el panorama general. Hablar sobre bytes de sobre es como hablar sobre el desenrollado de bucles cuando se compara una ordenación rápida con una ordenación de shell. Hay escenarios en los que SOAP puede funcionar mejor y hay escenarios en los que REST puede funcionar mejor. El contexto lo es todo.

REST obtiene gran parte de su ventaja de rendimiento al ser muy flexible sobre los tipos de medios que admite y al tener un soporte sofisticado para el almacenamiento en caché. Para que el almacenamiento en caché funcione bien, se deben cumplir casi todas las restricciones.

Su último punto sobre las URL legibles es, con mucho, el más irónico. Si realmente se compromete con la restricción de hipermedia, entonces cada URL podría ser un GUID y el desarrollador del cliente no perdería nada en la legibilidad.

El hecho de que los URI sean opacos para el cliente es una de las cosas más importantes al desarrollar sistemas REST. Las URL legibles son convenientes para el desarrollador del servidor y las URL bien estructuradas facilitan que el marco del servidor envíe las solicitudes, pero esos son detalles de implementación que no deberían tener ningún impacto en los desarrolladores que consumen la API.

La API de Twitter ni siquiera está cerca de ser RESTful y es por eso que no puede ver ningún beneficio al usarla a través de SOAP. La API de Netflix está mucho más cerca, pero su uso de tipos de medios genéricos demuestra que el incumplimiento de una sola restricción puede tener un profundo impacto en los beneficios derivados del servicio.

Puede que no sea toda su culpa

He dejado mucho de lado a los proveedores de servicios, pero se necesitan dos para bailar RESTAMENTE. Un servicio puede seguir todas las restricciones religiosamente y un cliente aún puede deshacer fácilmente todos los beneficios.

Si un cliente codifica las URL para acceder a ciertos tipos de recursos, entonces está evitando que el servidor cambie esas URL. Cualquier tipo de construcción de URL basada en el conocimiento implícito de cómo el servicio estructura sus URL es una violación.

Hacer suposiciones sobre qué tipo de representación se devolverá de un enlace puede generar problemas. Hacer suposiciones sobre el contenido de la representación basada en el conocimiento que no se menciona explícitamente en los encabezados HTTP definitivamente creará un acoplamiento que causará dolor en el futuro.

¿Deberían haber usado jabón?

Personalmente, no lo creo. REST hecho correctamente permite que un sistema distribuido evolucione a largo plazo. Si está creando sistemas distribuidos que tienen componentes desarrollados por diferentes personas y necesitan durar muchos años, entonces REST es una muy buena opción.

SOAP es un orientada a objetos , llamada a procedimiento remoto pila de tecnología. Funciona construyendo una nueva abstracción sobre un protocolo existente (HTTP).

REST es un enfoque orientado a documentos , que simplemente usa las características de un protocolo existente (HTTP). "REST" es solo una palabra de moda: el concepto es el siguiente: ¡simplemente use la web de la manera en que fue diseñada para funcionar!

En respuesta a las ediciones a la pregunta:

1. "La implementación de un servicio REST lleva infinitamente más tiempo que la implementación de un servicio SOAP".

   Um, no, no puede ser infinitamente más largo. Y en los casos en que lo que intenta recuperar ya es un documento o archivo , en realidad es mucho más rápido . Por ejemplo, la especificación OGC para WMS (Web Mapping Service) define una versión SOAP y REST del protocolo, y hay una razón por la cual casi nadie implementa la versión SOAP: es porque si está tratando de obtener un mapa, es es mucho más fácil construir una URL y recuperar bytes de imagen de esa URL que molestarse en encapsularlo en un mensaje SOAP. Pero sí, estaré de acuerdo en que si el objetivo del servicio web es transferir algún objeto fuertemente tipado en un modelo de objeto de dominio, SOAP es más adecuado para ese uso.

2. "¿Por qué escribir un servicio REST que devuelve XML de todos modos?"

   Bueno, sí, eso puede ser tonto. Pero depende de cuál sea el XML. Si hay un esquema claramente definido para él en alguna parte, entonces no hay ambigüedad. Por ejemplo, puede pensar en las URL de WSDL como un tipo de servicio web RESTful para recuperar información sobre un servicio web. En este caso, agregar la sobrecarga de otra solicitud SOAP no tendría sentido.

   En general, REST gana cuando el contenido que se transfiere puede considerarse como un archivo, como una sola unidad . SOAP gana cuando el contenido debe tratarse como un objeto con miembros .

3. "He escuchado la queja de que con SOAP tienes la" sobrecarga "del SOAP Envelope. En estos tiempos, ¿realmente debemos preocuparnos por un puñado de bytes?"

   Si. No en todas las circunstancias, pero hay sitios con mucho tráfico que marcan la diferencia. ¿Es suficiente diferencia para superar las diferencias semánticas de usar SOAP en lugar de REST? Lo dudo. Si está haciendo un protocolo de comunicación remota de objetos y la cantidad de bytes está haciendo una diferencia, SOAP probablemente no sea la herramienta para usted de todos modos, tal vez debería usar CORBA o DCOM en su lugar.

4. "Escuché el argumento de que con REST puedes simplemente abrir la URL en el navegador y ver los datos".

   Sí, y este es un gran argumento a favor de REST si tiene sentido ver los datos en un navegador . Por ejemplo, con los datos de imagen, es una manera fácil de depurar el servicio: simplemente pegue la URL en la barra de direcciones de su navegador y vea cómo se ve la imagen. O si los datos devueltos están en XML y tiene una hoja de estilo XML referenciada que se convierte en HTML legible en el navegador, entonces obtiene el beneficio del marcado semántico y la fácil visualización, todo en un solo paquete. Pero tiene razón, este beneficio se evapora principalmente cuando se trabaja con esquemas de autenticación más complejos. Si no puede codificar toda su información de autenticación en cada solicitud HTTP , entonces diría que no cuenta como REST en absoluto.

5. "¿Por qué necesitamos una URL" legible "para cada recurso? Si estuviéramos usando una herramienta para implementar el servicio, ¿realmente nos importa la URL real?"

   Bueno, eso depende. ¿Por qué necesitamos URL legibles para cualquier recurso en la web? Puede leer el ensayo de Tim Berners-Lee Los URI geniales no cambian por la justificación, pero básicamente, mientras el recurso aún pueda ser útil en el futuro, el URI para ese recurso debería permanecer igual.

   Obviamente, para los recursos transitorios (como el enlace "El dinero de hoy" en el ensayo) no es necesario, ya que la necesidad de hacer referencia al recurso desaparece si el recurso correspondiente desaparece. Pero para recursos más permanentes (como las preguntas de StackOverflow, por ejemplo, o películas en IMDB), desea tener una URL que funcione para siempre. Cuando diseña un servicio web, debe decidir si los recursos en sí mismos podrían sobrevivir a su servicio, y si es así, entonces REST es probablemente el camino correcto.

Para el registro, sí, he estado desarrollando páginas web desde mucho antes de que existieran NetFlix o Twitter. Y no, todavía no he tenido ninguna necesidad u oportunidad de implementar un cliente para los servicios de NetFlix o Twitter. Pero incluso si sus servicios son atrozmente difíciles de trabajar, eso no significa que la tecnología en la que implementaron sus servicios sea mala, solo que esas dos implementaciones son malas.

Para resumir: REST y SOAP son solo herramientas . Cada uno tiene fortalezas y debilidades. Si la única herramienta que tiene es un martillo, entonces cada problema parece un clavo. Conozca ambas herramientas y aprenda a usarlas correctamente, y luego elija la herramienta adecuada para cada trabajo.

Una pregunta honesta merece una respuesta honesta. Pero primero, ¿por qué usó el texto de esta pregunta como respuesta a otra pregunta si no pensó que era de naturaleza retórica?

De todas formas:

1. " Existen herramientas para que todos los lenguajes / frameworks / plataformas modernos puedan leerse en un WSDL y generar clases proxy y clientes. La implementación de un servicio REST se realiza a mano leyendo la documentación " .

   Al igual que los proveedores de navegadores han leído y releído la especificación HTML 4.01 arriba y abajo para intentar implementar una experiencia de navegación consistente. ¿Ha reflexionado sobre el hecho de que los navegadores se inventaron mucho antes de la banca por Internet y el stackoverflow y, sin embargo, puede usar un navegador para hacer exactamente esas cosas? Esto es posible debido a la única razón por la que todos aceptan usar HTML (y formatos relacionados como CSS, JS, JPEG, etc.).

   Los blogs en realidad no son tan nuevos, y a alguien se le ocurrió AtomPub, que permite que cualquier software de blogs acceda y actualice publicaciones en un blog, al igual que cualquier navegador web puede acceder a cualquier página web. Eso es bastante bueno y funciona debido a las restricciones RESTful impuestas por el protocolo.

   Pero para Twitter y Netflix, no existe un acuerdo universal de que "todos los microblogs existentes deben usar la aplicación / tweet de tipo de medio", principalmente porque el microblogging es muy nuevo. Tal vez dentro de unos años, algunos servicios de microblogging se instalen en la misma API para que Twitter, Facebook, Identica y puedan interoperar. Ninguna de sus API existentes está cerca de RESTful, por mucho que digan, por lo que no espero que suceda muy pronto.

   " Además, al implementar estos dos servicios, debe hacer" conjeturas "sobre lo que volverá a aparecer a través de la tubería, ya que no existe un esquema real o documento de referencia " .

   Has dado en el clavo. REST se trata de distribuido e hipermedia, y eso lo resume bastante. Un navegador mira lo que obtiene de una solicitud y se lo muestra al usuario. Una página HTML generalmente genera muchas más solicitudes GET, por ejemplo CSS, scripts e imágenes. Por lo general, una imagen solo se representa en la pantalla, se ejecuta JavaScript, etc. Cada vez, el navegador hace lo que hace porque encontró el enlace en una etiqueta <img>o <style>y el tipo de medio de respuesta fue image/jpego text/css.

   Si Twitter crea una API basada en hipermedia, probablemente siempre devolverá una application/tweetcada vez que siga un enlace a un tweet, pero el cliente nunca debe asumirlo, y siempre debe verificar qué obtiene antes de actuar en consecuencia.

2. " ¿Por qué escribir un servicio REST que devuelve XML de todos modos? "

   Todo esto se reduce a tipos de medios. Al igual que HTML, si ve un elemento que no tiene idea de lo que realmente significa, la especificación HTML le indica que los ignore y procese el "cuerpo" de la etiqueta si tiene uno. Del mismo modo, la especificación del átomo le indica que ignore los elementos desconocidos y el marcado extraño (de diferentes espacios de nombres) y que no procese el cuerpo (IIRC).

   Diseñar tipos de medios para dominios con problemas genéricos (como en el tipo de medios HTML para el dominio con problemas de texto enriquecido ) es muy difícil. Hacer tipos de medios para dominios con problemas muy estrechos es probablemente mucho más fácil (como un tweet). Pero siempre es una buena idea diseñar para la extensibilidad y especificar cómo deben reaccionar los clientes (y los servidores) cuando ven elementos o elementos de datos que no coinciden con las especificaciones. JPEG, por ejemplo, tiene un tipo de registro específico de la aplicación (por ejemplo, APP1) que se utiliza para contener todo tipo de metadatos.

3. " Escuché la queja de que con SOAP tienes la" sobrecarga "del SOAP Envelope. En estos días, ¿realmente debemos preocuparnos por un puñado de bytes? "

   No, nosotros no. REST no se trata en absoluto de ser eficiente a través del cable, en realidad está cambiando la eficiencia del cable. La eficiencia de REST proviene de las posibilidades de almacenamiento en caché habilitadas por todas las otras restricciones: Notas de disertación de Fielding : Sin embargo, la compensación es que una interfaz uniforme se degrada eficiencia, ya que la información se transfiere de forma estandarizada en lugar de una que sea específica para las necesidades de una aplicación. La interfaz REST está diseñada para ser eficiente para la transferencia de datos hipermedia de gran tamaño, optimizando para el caso común de la Web, pero resultando en una interfaz que no es óptima para otras formas de interacción arquitectónica. No creo que la sobrecarga del recuento de bytes del sobre SOAP sea una preocupación válida.

4. " Escuché el argumento de que con REST puedes simplemente abrir la URL en el navegador y ver los datos " .

   Sí, eso también es un argumento no válido. No funciona de esa manera. Incluso si funcionó, la mayoría de las API REST más estrechas utilizan tipos de medios de los que los navegadores no tienen idea y todavía no funcionarán.

   Pero hay muchas más posibilidades que un navegador para probar una API basada en HTTP, como utilidades de línea de comandos o extensiones de navegador que le permiten controlar casi cualquier aspecto de una solicitud HTTP, inspeccionar encabezados de respuesta y descubrir enlaces para que usted los siga. Pero aun así, esto no es tan fácil como generar stubs WSDL y hacer un programa de tres líneas para llamar a la función de todos modos.

5. " ¿Por qué necesitamos una URL" legible "para cada recurso? Si estuviéramos usando una herramienta para implementar el servicio, ¿realmente nos importa la URL real? "

   Si observa cómo funciona la web, estoy bastante seguro de que los humanos en general están contentos de que el URI para una página de Wikipedia se vea así, en http://en.wikipedia.org/wiki/Stack_overflowlugar de hacerlo http://en.wikipedia.org/wiki/?oldid=376349090. Pero en realidad no es importante DESCANSAR. Lo importante para tratar de hacerlo bien es elegir colocar datos relevantes en el URI que probablemente no cambien. Puede pensar que el ID de la base de datos nunca cambiará, pero ¿qué sucede cuando se deben fusionar dos conjuntos de datos? Todas sus claves principales cambian. El título de la página (Stack_overflow) no cambiará.

Perdón por la larga respuesta, pero creo que esta pregunta es válida y no se ha abordado antes aquí en SO. Estoy seguro de que Darrel Miller agregará su respuesta una vez que regrese también.

Editar: formateo

Martin Fowler tiene una publicación sobre el Modelo de Madurez Richardson que hace un gran trabajo explicando la diferencia entre SOAP y REST.

WSDL y otros protocolos a nivel de documento son redundantes. El protocolo HTTP admite un conjunto de operaciones mucho más rico además de servir documentos y enviar formularios.

Los partidarios de REST se sienten incómodos con esa redundancia.