restful - servicios soap

¿Debería un servicio web de Netflix o Twitter usar REST o SOAP? (5)

Martin Fowler tiene una publicación sobre Richardson Madurity Model que hace un excelente trabajo al explicar la diferencia entre SOAP y REST.

Implementé dos servicios REST: Twitter y Netflix. Ambas veces, tuve problemas para 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 cuenta de lo que me estoy perdiendo y explicar por qué se usó REST como la implementación del servicio para servicios como estos.

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

2) ¿Por qué escribir un servicio REST que devuelva XML de todos modos? La única diferencia es que con REST no se conocen los tipos que representa cada elemento / atributo: usted es el único que puede implementarlo y esperar que un día una cadena no se encuentre en un campo que usted pensó que era siempre un int. SOAP define la estructura de datos utilizando WSDL, por lo que no es necesario.

3) He escuchado la queja de que con SOAP tiene la "sobrecarga" del Sobre SOAP. En este día y edad, ¿realmente tenemos que preocuparnos por un puñado de bytes?

4) He escuchado el argumento de que con REST puede simplemente insertar la URL en el navegador y ver los datos. Claro, si su servicio REST usa autenticación simple o sin autenticación. El servicio de Netflix, por ejemplo, usa OAuth, que requiere que usted firme cosas y codifique cosas antes de que pueda enviar su solicitud.

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

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

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

En respuesta a ediciones para preguntar:

"Implementar un servicio REST lleva infinitamente más tiempo que implementar un servicio SOAP".
Um, no, no puede ser infinitamente más largo. Y en los casos en que lo que está tratando de 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 simplemente construir una URL y recuperar bytes de imágenes de esa URL de lo que es molestarse con encapsularla 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 objetos de dominio, SOAP es más adecuado para ese uso.
"¿Por qué escribir un servicio REST que devuelva XML de todos modos?"
Bueno, sí, eso puede ser tonto. Pero depende de lo que es 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 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 sería inútil.
En general, REST gana cuando el contenido que se transfiere se puede considerar como un archivo, como una sola unidad . SOAP gana cuando el contenido debe tratarse como un objeto con miembros .
"He escuchado la queja de que con SOAP tienes la" sobrecarga "del Sobre SOAP. En esta época, ¿realmente tenemos que preocuparnos por un puñado de bytes?"
Sí. No en todas las circunstancias, pero hay sitios con mucho tráfico donde hace la diferencia. ¿Es suficiente la diferencia para compensar las diferencias semánticas de usar SOAP en lugar de REST? Lo dudo. Si está haciendo un protocolo de interacción remota entre objetos y el número de bytes está haciendo la diferencia, es posible que SOAP no sea la herramienta para usted de todos modos, tal vez debería usar CORBA o DCOM en su lugar.
"He escuchado el argumento de que con REST solo puede mostrar 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 visualización fácil 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 argumentaría que no cuenta como REST en absoluto.
"¿Por qué necesitamos una URL legible para cada recurso? Si utilizáramos 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. Cool URIs No cambian por la razón fundamental, pero básicamente, siempre que el recurso siga siendo útil en el futuro, el URI de ese recurso debería permanecer igual.
Obviamente, para recursos transitorios (como el enlace "dinero de hoy" en el ensayo) no es necesario, ya que la necesidad de referenciar el recurso desaparece si el recurso correspondiente desaparece. Pero para obtener recursos más permanentes (como preguntas de , 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í podrían sobrevivir a su servicio y, de ser así, entonces REST probablemente sea el camino correcto.

Para el registro, sí, he estado desarrollando páginas web desde mucho antes de que NetFlix o Twitter existieran. Y no, todavía no he tenido la necesidad ni la oportunidad de implementar un cliente en los servicios de NetFlix o Twitter. Pero incluso si sus servicios son atrozmente difíciles de trabajar, eso no significa que la tecnología sobre 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 tienes 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é usaste el texto de esta pregunta como respuesta a otra pregunta si no crees que sea retórica por naturaleza?

De todas formas:

" Existen herramientas para todos los lenguajes / frameworks / plataformas modernos para leer en un WSDL y sacar clases de proxy y clientes. La implementación de un servicio REST se hace a mano leyendo la documentación " .
Al igual que los proveedores de navegadores han leído y vuelto a leer la especificación de HTML 4.01 hacia arriba y hacia abajo para tratar de implementar una experiencia de navegación coherente. ¿Ha reflexionado sobre el hecho de que los navegadores se inventaron mucho antes de la banca por Internet y , y aún así, puede usar un navegador para hacer exactamente eso? 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 alguien creó AtomPub, que permite a cualquier software de blogs acceder y actualizar publicaciones en un blog, al igual que cualquier navegador web puede acceder a cualquier página web. Eso es bastante limpio, 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 que existen usen el tipo de medio application / tweet", principalmente porque los microblogs son tan nuevos. Tal vez en unos pocos años algunos servicios de microblogging se asienten en la misma API para que Twitter, Facebook, Identica y puedan interoperar. Ninguna de sus API existentes está cerca de RESTful, por mucho que reclamen, 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 en el conducto, ya que no existe un esquema real o documento de referencia " .
Has golpeado el clavo en la cabeza. REST tiene que ver con distribuido e hipermedia, y eso lo resume bastante bien. Un navegador analiza qué 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 <img> o <style> y el tipo de medio de respuesta fue image/jpeg o text/css .
Si Twitter crea una API basada en hipermedia, probablemente siempre devuelva una application/tweet cada vez que sigas un enlace a un tweet, pero el cliente nunca debe asumirlo, y siempre verifica lo que obtiene antes de actuar sobre él.
" ¿Por qué escribir un servicio REST que devuelva XML de todos modos? "
Todo esto se reduce a los 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 procesa el "cuerpo" de la etiqueta si tiene uno. Del mismo modo, la especificación de átomo le indica que ignore los elementos desconocidos y el marcado externo (de diferentes espacios de nombres) y no procese el cuerpo (IIRC).
Diseñar tipos de medios para dominios de problemas genéricos (como en el tipo de medio HTML para el dominio de problemas de texto enriquecido ) es muy difícil. Hacer tipos de medios para dominios de problema 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 se supone que los clientes (y los servidores) deben reaccionar cuando ven elementos o elementos de datos que no coinciden con la especificación. 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.
" He escuchado la queja de que con SOAP tienes la" sobrecarga "del Sobre SOAP. En esta época, ¿realmente tenemos que preocuparnos por un puñado de bytes? "
No, nosotros no. REST no se trata de ser eficiente a través del cable, en realidad está negociando la eficiencia de los cables. La eficiencia de REST proviene de las posibilidades del almacenamiento en caché habilitado por todas las otras restricciones: Notas de disertación de Fielding : Sin embargo, la compensación es una interfaz uniforme 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 a gran escala, optimizándose para el caso común de la Web, pero dando como resultado una interfaz que no es óptima para otras formas de interacción arquitectónica. No creo que la sobrecarga del conteo de bytes de SOAP sea una preocupación válida.
" He escuchado el argumento de que con REST solo puede mostrar la URL en el navegador y ver los datos " .
Sí, eso también es un argumento inválido. No funciona de esa manera. Incluso si funcionó, la mayoría de las API REST estrechas usan tipos de medios que los navegadores no tienen idea y que aún 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 los encabezados de respuesta y descubrir los enlaces que debe seguir. Pero aún 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.
" ¿Por qué necesitamos una URL legible para cada recurso? Si utilizáramos una herramienta para implementar el servicio, ¿realmente nos importa la URL real? "
Si miras cómo funciona la web, estoy bastante seguro de que los humanos estamos contentos de que el URI para una página de wikipedia se vea así, http://en.wikipedia.org/wiki/Stack_overflow lugar de http://en.wikipedia.org/wiki/?oldid=376349090 . Pero en realidad no es importante DESCANSAR. Lo importante para intentar hacerlo bien es elegir colocar datos relevantes en el URI que probablemente no cambien. Podría pensar que la ID de la base de datos nunca cambiará, pero ¿qué sucede cuando se deben fusionar dos conjuntos de datos? Todas sus llaves principales cambian. El título de la página (Stack_overflow) no cambiará.

Perdón por la respuesta larga, 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: formatear

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

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

Un canario en una mina de carbón.

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

Las señales de advertencia

Tiene toda la razón, le toma más tiempo construir clientes RESTful que los clientes SOAP. Los kits de herramientas de SOAP eliminan un gran número de códigos repetitivos y hacen que los objetos proxy de los clientes 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 tan molestos para los desarrolladores de los clientes. ¿Qué se supone que debemos hacer con esa cantidad de datos?

Afortunadamente, muchos sitios que brindan servicios REST también brindan una gran cantidad de bibliotecas de clientes para que podamos usar esas bibliotecas para tener acceso a un grupo de objetos fuertemente tipados. Aunque parece un poco tonto. Si hubieran usado SOAP, podríamos haber codificado esas clases de proxy nosotros mismos.

SOAP overhead, ha. Es latencia que mata. Si la gente está realmente preocupada por la cantidad de bytes en exceso que cruzan el cable, quizás HTTP no sea la opción correcta. ¿Has visto cuántos bytes usa el encabezado de usuario-agente?

Sí, ¿alguna vez has intentado usar un navegador web como herramienta de depuración para algo que no sea HTML y JavaScript? Créeme, apesta. Solo puedes usar dos de los verbos, el almacenamiento en caché se interpone constantemente, el manejo de errores absorbe tanta información, está constantemente buscando un maldito favicon.ico. Sólo disparame.

URL legible Solo sustantivos, sin verbos. Sí, eso es fácil siempre que solo estemos haciendo operaciones CRUD y solo necesitamos 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 gran cantidad de desarrolladores de aplicaciones que desarrollan aplicaciones que se integran con los servicios REST y que están en el proceso de llegar al mismo conjunto de conclusiones que usted tiene. Se les prometió simplicidad, flexibilidad, escalabilidad, evolución y el santo grial de la reutilización fortuita. Las características de la web en sí, ¿cómo pueden salir cosas?

Sin embargo, descubren que el control de versiones es un gran 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 evolucionan las estructuras de datos y se refactorizan las URL. Diseñar API alrededor de los nombres y los cuatro verbos puede ser realmente difícil, especialmente con los fanáticos de Url RESTful que le dicen cuándo puede y no puede usar cadenas de consulta.

Los desarrolladores van a comenzar a preguntar por qué estamos perdiendo nuestro esfuerzo en el soporte de formatos Json y formatos Xml, ¿por qué no solo enfocar nuestros esfuerzos en uno y hacerlo bien?

¿Cómo te fue tan mal?

Te diré lo que salió mal. Nosotros, como desarrolladores, permitimos 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, nosotros los desarrolladores ya sabemos cómo hacerlo, hemos estado tratando con bases de datos durante años que tienen tablas y columnas y sentencias de SQL que tienen SELECCIONAR, INSERTAR, ACTUALIZAR y ELIMINAR. Debería haber sido un pedazo de pastel.

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

Esta versión suavizada de REST se validó en la cultura del desarrollador de muchas maneras. Se crearon marcos de servidores que fomentaban la identificación de recursos y la interfaz uniforme, pero no hicieron nada para respaldar las otras limitaciones. Los términos comenzaron a flotar en torno a la diferenciación de los enfoques (HI-REST frente a LO-REST, RESTO corporativo frente a RESTO académico, RESTO frente a REST).

Algunas personas gritan que si no aplicas todas las restricciones, no es REST. No obtendrás los beneficios. No hay medio RESTO. Pero esas voces fueron etiquetadas como fanáticos religiosos que estaban molestos por el hecho de que su precioso término había sido robado de la oscuridad e incorporado a la corriente principal. Los celosos 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 propiedades web principales que tienen una API admiten "REST". Twitter y Netflix son dos de alto perfil. Lo aterrador es que solo puedo pensar en una API pública que sea autodescriptiva y hay algunas que realmente implementan la restricción de hipermedios. Seguro que algunos sitios como y Gowalla admiten enlaces en sus respuestas, pero hay enormes agujeros en sus enlaces. La API de no tiene página raíz. ¡Imagine qué éxito habría tenido el sitio web si no hubiera una página de inicio para el sitio web!

Fuiste engañado, tengo miedo

Si ha llegado hasta aquí, la respuesta breve a su pregunta es que esas API (Netflix y Twitter) no se ajustan a todas las restricciones y, por lo tanto, no obtendrá los beneficios que se supone que aportan las APIS 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. Tome el ejemplo clásico de un navegador web. ¿A cuántos servicios puede acceder un navegador web? ¿Qué tal un lector de feeds? Ahora, ¿a cuántos servicios diferentes puede acceder el cliente promedio de Twitter? Sí, solo uno.

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

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

Usted es absolutamente correcto para servicios como Twitter. Sin embargo, la restricción autodescriptiva en REST dice que el encabezado de tipo de contenido HTTP debe describir exactamente el contenido que se está transmitiendo a través del cable. La entrega de la aplicación / json y la aplicación / xml no le dice nada sobre el contenido.

Cuando se trata de considerar el rendimiento de los sistemas basados en REST, es necesario mirar la imagen más grande. Hablar de bytes de sobre es como hablar de desenrollar bucles al comparar una clasificación rápida con una clasificación de shell. Hay escenarios donde SOAP puede tener un mejor rendimiento, y hay escenarios donde REST puede tener un mejor rendimiento. El contexto es todo.

REST obtiene gran parte de su ventaja de rendimiento al ser muy flexible con respecto a los tipos de medios que admite y con 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 de lejos el más irónico. Si realmente se compromete con la restricción de hipermedios, 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 de trabajo del servidor envíe solicitudes, pero esos son detalles de implementación que no deberían afectar a los desarrolladores que consumen la API.

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

Puede que no sea su culpa

Hice un montón de dumping en los proveedores de servicios, pero se necesitan dos para bailar RESTfully. 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 impide que el servidor cambie esas URL. Cualquier construcción de URL de tipo 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á desde un enlace puede generar problemas. Hacer suposiciones sobre el contenido de la representación basada en el conocimiento que no está explícitamente establecido en los encabezados HTTP definitivamente va a crear un acoplamiento que causará dolor en el futuro.

¿Deberían haber usado SOAP?

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