¿Por qué necesitamos servicios web RESTful?

Question

Voy a aprender servicios web RESTful (es mejor decir que tendré que hacer esto porque es parte del programa de maestría CS).

He leído información en Wikipedia y también he leído un artículo sobre REST en Sun Developer Network y veo que no es una tecnología fácil, existen marcos especiales para construir aplicaciones RESTful, y a menudo se compara con Los programadores y los servicios web de SOAP deben comprender cuándo usar SOAP y cuándo REST podría ser un buen enfoque.

Recuerdo que hace varios años SOAP era muy popular (¿de moda?) Y el artículo "SOAP" tenía que estar presente en cada buen CV. Pero en la práctica se usó muy raramente y para lograr propósitos muy simples.

Me parece que REST es otra "última palabra de moda" (o puedo estar totalmente equivocado porque no he visto REST en la práctica).

¿Puede darme algunos ejemplos donde se debe utilizar REST y por qué no podemos hacer lo mismo sin REST (o por qué deberíamos dedicar mucho más tiempo para hacer lo mismo sin REST)?

UPD: Desafortunadamente no veo argumentos concretos que puedan hacerme pensar en los primeros comentarios. ¡Hazme pensar que REST es una tecnología increíble!

me gustaría ver respuestas como esta:

que estaba desarrollando otra aplicación compleja HelloWorld y tenemos que lotes de transferencia de datos/minúsculas y yo solución RESTO propuesto a mi compañero de trabajo:

– ¡Oh, maldición! Jonny, debemos sin duda utilizar REST para implementar esta aplicación!
– Sí, Billy, nosotros podemos usar REST, pero sería mejor usar SOAP. Confíe en mí porque sé algo sobre el desarrollo de aplicaciones HelloWorld .
– Pero SOAP es tecnología pasada de moda del último siglo y podemos utilizar mejor uno.
– Billy, ¿estás listo para pasar 3 días para experimentar con RESTO? Podemos hacer esto con SOAP en 2 horas ..
– Sí, estoy seguro que pasaremos aún más tiempo a lograr la misma seguridad/rendimiento/ /escalabilidad/lo que sea con SOAP. Estoy seguro de que las aplicaciones HelloWorld deberían desarrollarse solo con REST a partir de ahora.

Answer 1

resto debe ser utilizado si es muy importante que minimizar el acoplamiento entre los componentes de cliente y servidor en una aplicación distribuida.

Este puede ser el caso si su servidor va a ser utilizado por muchos clientes diferentes que no tiene control. También puede ser el caso si desea poder actualizar el servidor regularmente sin necesidad de actualizar el software del cliente.

Puedo asegurarle que lograr este bajo nivel de acoplamiento es no es fácil de hacer. Es fundamental seguir todas las restricciones de REST para tener éxito. Mantener una conexión puramente sin estado es difícil. Elegir los tipos de medios adecuados y exprimir sus datos en los formatos es complicado. Crear sus propios tipos de medios puede ser aún más difícil.

La adaptación del comportamiento del servidor enriquecido en la interfaz HTTP uniforme puede ser confusa y, a veces, parece pedante en comparación con el enfoque RPC relativamente sencillo.

A pesar de las dificultades, los beneficios son que tiene un servicio que un desarrollador de cliente debería poder entender fácilmente debido al uso constante del protocolo HTTP. El servicio debe ser fácilmente detectable debido a hypermedia y el cliente debe ser extremadamente resistente a los cambios en el servidor.

Las ventajas de hipermedia y la evitación del estado de la sesión hace que el balanceo de carga sea simple y sea posible el partición del servicio. La estricta conformidad con las reglas HTTP hace que la disponibilidad de herramientas como depuradores y proxies de almacenamiento en caché sea algo maravilloso.

actualización

Me parece que el descanso es otra 'última palabra de moda' (o puedo ser totalmente equivocado porque no tengo jamás RESTO visto en la práctica).

Creo que REST se ha puesto de moda porque las personas que intentan hacer proyectos de tipo SOA han descubierto que al usar la pila SOAP no se dan cuenta de los beneficios que se les prometieron. La gente sigue volviendo a la web como un ejemplo de metodologías simples de integración. Desafortunadamente, creo que las personas subestiman la cantidad de planificación y previsión que se emplearon para crear la web y simplifican demasiado lo que se debe hacer para permitir el tipo de reutilización fortuita que se produce en la web.

Usted dice que nunca ha visto REST en la práctica, pero que no puede ser cierto si alguna vez utiliza un navegador web. El navegador web es un cliente REST.

• ¿Por qué no hay que hacer una actualización del navegador cuando alguien cambia algo de HTML en un sitio web?
• ¿Por qué puedo agregar un nuevo conjunto completo de páginas a un sitio web y el "cliente" todavía puede acceder a esas páginas nuevas sin una actualización?
• ¿Por qué no tienen que ofrecer un "servicio de descripción de lenguaje" al navegador web para decirle que cuando se va a http://example.org/images/cat que el tipo de retorno será una imagen jpeg y al momento a http://example.org/description/cat el tipo de devolución será text/html?
• ¿Por qué puedo utilizar un navegador web para visitar sitios que no existían cuando se lanzó el explorador ? ¿Cómo puede el cliente conocer estos sitios?

Puede parecer una pregunta tonta, pero si conoce la respuesta, entonces puede comenzar a ver de qué se trata REST. Mire StackOverflow para obtener más beneficios de REST. Cuando estoy buscando una pregunta, puedo marcar esa página o enviar la url a un amigo y él puede ver la misma información. Él no tiene que navegar por el sitio para encontrar esa pregunta.

StackOverflow utiliza una variedad de servicios OpenId para autenticación, gravatar.com para imágenes de avatar, google-analytics y Quantserve para información analítica. Este tipo de integración multi-compañía es el tipo de cosa que el mundo SOAP solo sueña con. Uno de los mejores ejemplos es el hecho de que las bibliotecas de jQuery que se utilizan para controlar la interfaz de usuario de StackOverflow se recuperan de la red de entrega de contenido de Google. El hecho de que SO pueda dirigir al cliente (es decir, su navegador web) para descargar código de un sitio de terceros para mejorar el rendimiento es prueba del bajo acoplamiento entre el cliente web y el servidor.

Estos son ejemplos de una arquitectura REST en funcionamiento.

Ahora algunos sitios web/aplicaciones hacen rompen las reglas de REST y luego el navegador no funciona como se esperaba.

• El infame botón de retroceso problema es causado por el uso del lado del servidor estado de la sesión.
• El equilibrio de carga puede ser un problema cuando tiene estado de sesión del lado del servidor.
• Las aplicaciones flash a menudo evitan que la URL identifique específicamente una representación .
• El otro problema que rompe los navegadores web es una mala conformidad con los estándares de tipo de medios . Oímos todos el momento de cómo IE6 debe ser asesinado. El problema es que los estándares no se siguieron correctamente, o se ignoraron por cualquier motivo.
• El uso de sesiones de inicio de sesión es la fuente de muchos agujeros de seguridad.

REST está por todos lados. Es la parte de la web que lo hace funcionar bien. Si desea construir aplicaciones distribuidas que puedan escalar como la web, sea flexible para cambiar como la web y promueva la reutilización como lo hizo la web, entonces siga las mismas reglas que cuando crearon navegadores web.

Answer 2

De here:

ventajas REST:

• Ligero - no un montón de marcado XML adicional
• humanamente legible Resultados
• fácil de construir - encontraron herramientas necesarias

comprobación también this a cabo:

Para ser justos, RESTO no es la mejor solución para cada servicio Web. Los datos que deben ser seguros no se deben enviar como parámetros en los URI. Y grandes cantidades de datos, como los detallados en las órdenes de compra, pueden convertirse rápidamente en engorrosos o incluso fuera de límites dentro de un URI. En estos casos, SOAP es de hecho una solución sólida. Pero es importante probar REST primero y recurrir a SOAP solo cuando sea necesario. Esto ayuda a mantener el desarrollo de aplicaciones simple y accesible.

Answer 3

REST se inició, según mi conocimiento, por la disertación Architectural Styles and the Design of Network-based Software Architectures de Roy Fielding, que vale la pena leer si no la ha mirado.

En la parte superior de la tesis es una cita:

Casi todo el mundo se siente en paz con la naturaleza: escuchando el océano olas contra la costa, junto a un lago quieto, en un campo de hierba, en una brezo soplado por el viento. Un día, cuando hayamos aprendido el modo intemporal otra vez, sentiremos lo mismo con respecto a nuestras ciudades, y nos sentiremos como con mucha paz en ellas, como lo hacemos hoy caminando junto al océano, o tendido en el largo hierba de un prado.

- Christopher Alexander, The Timeless manera de construir (1979)

Y eso realmente resumir allí. REST es en muchos sentidos más elegante.

SOAP es un protocolo en la parte superior de HTTP, por lo que pasa por alto una gran cantidad de convenciones HTTP para crear nuevas convenciones en SOAP, y es de varias maneras redundantes con HTTP. HTTP, sin embargo, es más que suficiente para recuperar, buscar, escribir y borrar información a través de HTTP, y eso es mucho de lo que REST es. Debido a que REST está construido con HTTP en lugar de encima de él, también significa que el software que desea integrarse con él (como un navegador web) no necesita entender SOAP para hacerlo, solo HTTP, que debe ser el más utilizado. ampliamente entendido e integrado, con protocolo en uso en este punto.

Answer 4

Para agregar un giro ligeramente prosaico a las respuestas ya dadas, el motivo por el que utilizamos servicios REST donde estoy es que si sabes que puedes entregarle a un socio comercial una URL y saber que recibirán, a cambio, una buena fuera del bloque de XML sin importar si están trabajando en .Net x.x, PHP, Python, Java, Ruby o Dios sabe qué reduce drásticamente los dolores de cabeza.

También significa que, en el extremo no techy, nuestros vendedores pueden jactarse de nuestra versátil API para las personas sin temor a parecerse a los muppets completos.

Mucho aparte de los beneficios técnicos, todo lo que sea fácil para un no techy explicar, demostrar y sentirse seguro es algo bueno. SOAP, aunque igual de genial para los expertos en tecnología es mucho menos accesible para los no tecnológicos y, por lo tanto, no es tan fácil de "vender".

Tiendo a darme cuenta de que las cosas que los no tecnológicos pueden captar tienden a quedarse. Así que dudo que REST sea una técnica susceptible de ser tan susceptible como SOAP a los caprichos de la moda.

Pero todo lo relacionado con no colocar nada en un servicio REST que debería estar bloqueado es doblemente cierto, aunque solo sea porque la tecnología es tan fácil de entender para las personas que no tienen una mente tan técnica.

Answer 5

Aquí están algunas ideas:

• RESTO limita su servicio para utilizar una interfaz uniforme. No tiene que perder el tiempo soñando despierto (o discutiendo) sobre todas las formas posibles en que su servicio podría funcionar: se pone a trabajar para identificar los recursos en su sistema. Resulta ser un gran trabajo en sí mismo, pero afortunadamente los problemas tienden a definirse mucho mejor.
• Con los recursos, sus asociaciones y sus representaciones en la mano, realmente hay muy poco que hacer en la implementación de su servicio porque se han tomado muchas decisiones para usted.
• Su sistema se parecerá mucho a otros sistemas RESTful; Se reducirán las curvas de aprendizaje para los compañeros de equipo, socios y clientes.
• Tendrás un vocabulario común para debatir sobre problemas de diseño con otros desarrolladores, e incluso con aquellos con una menor mentalidad técnica (como los clientes).
• Como dice Darrel, porque está utilizando un diseño hypertext-driven, su servicio reduce el alcance del acoplamiento a una sola cosa: tipos de medios. Esto lo ayuda como desarrollador porque los cambios en su sistema están contenidos dentro de una estrecha banda de contacto. Esto ayuda a sus clientes en que una menor cantidad de sus cambios romperá su código.
• Casi todos los problemas que pueda tener al implementar REST se pueden resolver con exposing a new resource o volver a pensar en su modelo de recursos. Este enfoque es, IMO, un gran impulso a la productividad.

En pocas palabras, REST elimina muchas de las decisiones de diseño e implementación más lentas y polémicas del flujo de trabajo de su equipo. Cambia su atención de implementando su servicio a diseñando. Y lo hace sin acumular gobbledygook en el protocolo HTTP.

Answer 6

La mayoría de las respuestas "profesionales" sobre REST parecen provenir de personas que nunca han desarrollado un servicio web SOAP o un cliente que utiliza un entorno que proporciona las herramientas adecuadas para la tarea. Se quejan de problemas que nunca he encontrado, usando Visual Studio .NET y Rational Web Developer de IBM. Supongo que si tiene que desarrollar servicios web o clientes en un lenguaje de scripting u otro idioma con poca o ninguna compatibilidad con herramientas, estas son quejas válidas.

También tengo que admitir que varios de los puntos "pro" suenan como cosas que realmente podrían ser ciertas, pero que nunca he visto un ejemplo que ilustre su valor. En particular, agradecería mucho que alguien publicara un comentario que contenga un enlace a un buen ejemplo de un servicio web REST.Esto debería ser uno que utiliza múltiples niveles de recursos, posiblemente en una jerarquía, y que utiliza los tipos de medios correctamente. Tal vez si miro un buen ejemplo, lo entenderé, en cuyo caso, volveré aquí y lo admitiré.

Answer 7

Puedo decir con seguridad que he pasado mucho tiempo para entender esto como un principiante, pero este es el mejor vínculo para comenzar con REST desde cero. http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Sólo para tirar de,

pensar en lo que es un "servicio web tradicional". Es una interfaz con "métodos" expuestos. Los clientes conocen el nombre, la entrada y la salida de los métodos y, por lo tanto, pueden llamarlos.

Ahora imagine una interfaz que no exponga "métodos". En cambio, expone "objetos". Entonces, cuando un cliente ve esta interfaz, todo lo que ve es uno o más "objetos". "Un objeto" no tiene entrada y salida - porque "no hace nada". Es un sustantivo, no un verbo. Es "una cosa de ", no "una acción".

Por ejemplo, piense en un servicio web tradicional que proporciona las condiciones meteorológicas actuales si le proporciona una ciudad. Probablemente tiene un método web como GetWeatherInfo() que toma una ciudad como entrada y proporciona datos meteorológicos como salida. Hasta ahora, es fácil para usted comprender cómo un cliente consumirá este servicio web.

Ahora imagine, en el lugar del servicio web anterior, hay uno nuevo que expone a las ciudades como objetos. Entonces, cuando lo ve como un cliente, en lugar de GetWeatherInfo(), puede ver Nueva York, Dallas, Los Ángeles, Londres, y así sucesivamente. Y estas ciudades no tienen ninguna aplicación métodos específicos que cuelguen de ellas - aparentemente son como gases inertes - ellos mismos no reaccionan.

Debe estar pensando, bueno, ¿cómo le ayuda eso, como cliente, al llegar al clima de Dallas? Llegaremos a eso en unos momentos.

Si todo lo que obtiene de un servicio web es un "conjunto de objetos", obviamente usted necesita una forma de "actuar sobre ellos". Los objetos en sí no tienen métodos para llamar, por lo que necesita un conjunto de acciones que puede aplicar al estos objetos. En otras palabras, necesitas "aplicar un verbo al sustantivo". Si ve un objeto, por ejemplo, una manzana, que es "un sustantivo", puede aplicar "un verbo" como comer, a él. Pero no todos los verbos se pueden aplicar a todos los sustantivos . Por ejemplo, puede conducir un automóvil, pero no puede conducir un televisor.

Por lo tanto, si un servicio web expone sólo los objetos, y se le pregunta - bueno, Vamos ahora a diseñar algunas acciones o verbos que "todos los clientes pueden aplicar a todos los objetos que ven" estándar, ...

Answer 8

REST es un estilo de arquitectura para el diseño de aplicaciones en red. La idea es que, en lugar de utilizar mecanismos complejos como CORBA, RPC o SOAP para conectar máquinas, HTTP simple se utiliza para hacer llamadas entre máquinas.

De muchas maneras, la propia World Wide Web, basada en HTTP, se puede ver como una arquitectura basada en REST. Las aplicaciones RESTful usan las solicitudes HTTP para publicar datos (crear y/o actualizar), leer datos (por ejemplo, realizar consultas) y eliminar datos. Por lo tanto, REST usa HTTP para las cuatro operaciones CRUD (Crear/Leer/Actualizar/Eliminar).

REST es una alternativa liviana a los mecanismos como RPC (llamadas a procedimiento remoto) y servicios web (SOAP, WSDL, et al.). Más adelante, veremos cuánto más REST simple es.

A pesar de ser simple, REST tiene todas las funciones; Básicamente, no hay nada que pueda hacer en los servicios web que no se pueda hacer con una arquitectura RESTful. REST no es un "estándar". Nunca habrá una recomendación del W3C para REST, por ejemplo. Y si bien existen marcos de programación de REST, trabajar con REST es tan simple que a menudo puede "hacer su propio esfuerzo" con características de biblioteca estándar en idiomas como Perl, Java o C#.