131 votos

¿Por qué uno utilizar REST en lugar de los servicios web?

Asistió a una demostración interesante en REST hoy, sin embargo, no podía pensar en una sola razón (ni era uno presentado) por qué REST es de ninguna manera mejor o más fácil de usar y de implementar que una pila de servicios web.

¿Cuáles son algunas de las razones por qué nadie en el "mundo real" resto utiliza en lugar de los Web Services?

142voto

Menos gastos generales (sin envoltura SOAP para envolver cada llamada)

Menos duplicación (HTTP ya que representa las operaciones como borrado, PUT, GET, etc. que de otro modo ser representado en un sobre SOAP).

Más estandarizados - HTTP operaciones se entienden bien y actuar en consonancia. Un poco de JABÓN implementaciones pueden obtener quisquillosos.

Más legible para los humanos y comprobables (más difícil de la prueba de JABÓN con solo un navegador).

No es necesario utilizar XML (y usted no lo tiene que para el JABÓN, pero no tendría sentido ya que estamos haciendo el análisis de la envolvente).

Las bibliotecas han hecho JABÓN (tipo de) fácil. Pero usted se abstracción de una gran cantidad de redundancia por debajo, como he señalado. sí, en teoría, el JABÓN puede ir por encima de otros medios de transportes, así como para evitar montar encima de una capa haciendo cosas similares, pero en realidad es sólo acerca de todo el JABÓN de trabajo que usted puede hacer es a través de HTTP.

33voto

spoon16 Puntos 17694

Descanso de los servicios son mucho más simples para consumir de JABÓN base (ordinario) de los servicios. La razón de esto es que el RESTO se basa en peticiones HTTP que permite a la intención de inferir el tipo de petición (GET = recupero, POST = escribir, DELTE = quitar, etc...) y es totalmente independiente. Por otro lado se podría argumentar que es menos flexible como lo hace con el concepto de un mensaje sobre que contiene la solicitud de contexto.

En mi experiencia JABÓN ha sido preferido por los servicios dentro de la empresa y el RESTO ha sido preferido por los servicios que se exponen como las Api públicas.

Con herramientas como WCF en el .NET marco es muy trivial para implementar un servicio como el DESCANSO o el JABÓN.

Algunos relevantes de la lectura:

10voto

Bruce Puntos 3473

Voy a asumir que cuando usted dice "web services" que significa JABÓN y la WS-* conjunto de normas. (De lo contrario, yo podría argumentar que el RESTO de los servicios son "servicios web".)

La canónica argumento es que el RESTO de los servicios son una aproximación más exacta para el diseño de la web, es decir, el diseño de HTTP y la infraestructura asociada. Por lo tanto, el uso de un servicio REST será más compatible con las herramientas de la web y técnicas.

Por supuesto, una vez que se profundice en los detalles, encontrarás que ambos enfoques tienen fortalezas en diferentes escenarios. Es de esos detalles que te interesa?

6voto

Piko Puntos 3470

Tengo que leer más excelente de Roy Fielding disertación sobre el tema. Él es un excelente caso y fue sin duda muy por delante de su tiempo cuando lo escribió (2000).

6voto

joelhardi Puntos 6538

RESTO de la implementación agnóstico y mucho más transparente, y esto hace que sea ideal para las Api públicas, especialmente para los grandes sitios web como Flickr, Amazon o Digg que están utilizando su Api como herramientas de marketing y realmente quiero que la gente a consumir sus datos. Que no quiero ser la mano que sostiene 1000s de novato desarrolladores que están tratando de depurar su lenguaje de secuencias de comandos de elección buggy del JABÓN de la biblioteca.

Frente a SOAP y WSDL, que son mejores para aplicaciones de interior, donde usted tiene la caída en las bibliotecas y conocido clueful personas en ambos extremos. (Y que tal vez no tienen que ocuparse de cosas como el Internet-la escala de equilibrio de carga, almacenamiento en caché de HTTP, etc.) Luego de obtener las Api que se auto-documentado, preservar los tipos etc. con cero trabajo.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X