web-services - servicios - tipos de web services

¿Por qué necesitamos servicios web RESTful? (8)

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 sencilla, existen marcos especiales para construir aplicaciones RESTful, y a menudo se compara con servicios web SOAP y el programador debe entender 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 ítem "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 nunca 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 a hacer lo mismo sin REST)?

UPD : Desafortunadamente no puedo ver ningún argumento concreto que pueda hacerme pensar en los primeros comentarios. ¡Hazme pensar que REST es una tecnología increíble!

Me gustaría ver respuestas como esta:

Estaba desarrollando otra aplicación HelloWorld compleja y necesitamos transferir muchos datos / minúsculos y propuse la solución REST a mi compañero de trabajo:
- ¡Oh demonios! Jonny, ¡ciertamente deberíamos usar REST para implementar esta aplicación!
- Sí, Billy, podemos usar REST, pero sería mejor usar SOAP. Confía en mí porque sé algo sobre el desarrollo de aplicaciones HelloWorld.
- Pero SOAP es una tecnología anticuada del siglo pasado y podemos usar una mejor.
- Billy, ¿estás listo para pasar 3 días experimentando con REST? Podemos hacer esto con SOAP en 2 horas ..
- Sí, estoy seguro de que pasaremos aún más tiempo para 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.

Aquí hay algunas ideas:

REST restringe su servicio para usar 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 problemas de diseño con otros desarrolladores, e incluso con aquellos que tienen una menor mentalidad técnica (como los clientes).
Como dice Darrel, debido a que 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 exponiendo un nuevo recurso o volviendo a pensar 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 la implementación de su servicio al diseño . Y lo hace sin acumular gobbledygook en el protocolo HTTP.

Desde here :

Ventajas de REST:

Ligero: no hay demasiados márgenes xml adicionales
Resultados legibles en humanos
Fácil de construir: no se necesitan herramientas

También mira this :

Para ser justos, REST 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.

El REST fue iniciado, que yo sepa, por la disertación de Roy Fielding Estilos arquitectónicos y el Diseño de arquitecturas de software basadas en red , que vale la pena leer si no lo ha mirado.

En la parte superior de la disertación hay una cita:

Casi todos se sienten en paz con la naturaleza: escuchando las olas del océano contra la costa, junto a un lago inmóvil, en un campo de césped, en un brezal tirado por el viento. Un día, cuando hayamos aprendido de nuevo el camino intemporal, sentiremos lo mismo con respecto a nuestros pueblos, y nos sentiremos tan en paz en ellos, como lo hacemos hoy caminando junto al océano, o tendidos en la hierba larga de un pueblo. prado.

- Christopher Alexander, The Timeless Way of Building (1979)

Y eso realmente lo resume ahí arriba. 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.

La mayoría de las respuestas "pro" 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 verdad, 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é.

Para agregar un giro ligeramente prosaico a las respuestas ya dadas, la razón por la que utilizamos los servicios REST donde estoy es que, si sabe, puede entregarle a un socio comercial una URL y saber que recibirá, a cambio, una losa de XML muy bien diseñada. no importa si están trabajando en .Net xx, PHP, Python, Java, Ruby o Dios sabe qué es lo que 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.

Además de los beneficios técnicos, es fácil explicar, demostrar y sentirse seguro acerca de algo que no es techy, 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 resolver 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 incluir 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.

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

Solo para atraerte,

Piensa 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 ni salida, porque "no hace nada". Es un sustantivo, no un verbo. Es "una cosa", no "una acción".
Por ejemplo, piense en un servicio web tradicional que proporcione 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 entender cómo un cliente consumirá este servicio web.
Ahora imagina, 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 (), ve a Nueva York, Dallas, Los Ángeles, Londres, etc. Y estas ciudades no tienen ningún método específico de aplicación que cuelgue de ellas, son aparentemente como gases inertes, ellos mismos no reaccionan.
Debe estar pensando, bueno, ¿cómo le ayuda eso, como cliente, a conocer el clima de Dallas? Llegaremos a eso en unos momentos.
Si todo lo que obtienes de un servicio web es un "conjunto de objetos", obviamente necesitas una forma de "actuar sobre ellos". Los objetos en sí mismos no tienen métodos para llamar, por lo que necesita un conjunto de acciones que pueda aplicar a estos objetos. En otras palabras, necesitas "aplicar un verbo al sustantivo". Si ve un objeto, por ejemplo, una manzana, que es "un sustantivo", puede aplicarle "un verbo" como comer. 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 solo objetos, y se le pregunta, bueno, diseñemos algunas acciones estándar o verbos que "todos los clientes puedan aplicar a todos los objetos que ven", ...

REST es un estilo de arquitectura para diseñar 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.

En muchos sentidos, la propia World Wide Web, basada en HTTP, puede verse como una arquitectura basada en REST. Las aplicaciones RESTful usan 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 procedimientos remotos) 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 #.

Se debe utilizar REST si es muy importante que minimice el acoplamiento entre los componentes del cliente y del servidor en una aplicación distribuida.

Este puede ser el caso si su servidor va a ser utilizado por muchos clientes diferentes sobre los 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 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 el desarrollador del cliente debe poder entender fácilmente debido al uso constante del protocolo HTTP. El servicio debe ser fácilmente detectable debido a hipermedia y el cliente debe ser extremadamente resistente a los cambios en el servidor .

Los beneficios de hipermedia y el estado de evitación de sesión hacen que el equilibrio de carga sea simple y la partición de servicio sea factible . La estricta conformidad con las reglas HTTP hace que la disponibilidad de herramientas como depuradores y proxies de almacenamiento en caché sea algo maravilloso.

Actualizar

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

Creo que REST se ha puesto de moda porque las personas que intentan hacer proyectos tipo SOA han descubierto que al usar la pila SOAP no se dan cuenta de los beneficios prometidos. 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 necesita hacer una actualización del navegador cuando alguien cambia algún html en un sitio web?
¿Por qué puedo agregar un nuevo conjunto completo de páginas a un sitio web y el "cliente" aún puede acceder a esas páginas nuevas sin una actualización?
¿Por qué no necesito proporcionar un "lenguaje de descripción de servicio" al navegador web para decirle cuándo va a http://example.org/images/cat que el tipo de retorno será una imagen jpeg y cuando vaya? a http://example.org/description/cat el tipo de devolución será text / html?
¿Por qué puedo usar un navegador web para visitar sitios que no existían cuando se lanzó el navegador? ¿Cómo puede el cliente saber sobre estos sitios?

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

utiliza una variedad de servicios OpenId para autenticación, gravatar.com para avatar images, google-analytics y Quantserve para información analítica. Este tipo de integración de múltiples compañías es el tipo de cosas con las que soña el mundo SOAP . Uno de los mejores ejemplos es el hecho de que las bibliotecas de jQuery que se utilizan para controlar la interfaz de usuario de 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 rompen las reglas de REST y luego el navegador no funciona como se esperaba.

El infame problema del botón de retroceso se debe al uso del estado de sesión del lado del servidor.
El equilibrio de carga puede convertirse en un problema cuando tiene el 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 pobre conformidad con los estándares de tipo de medios. Oímos todo el tiempo sobre cómo IE6 necesita 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á en todas partes. 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.