@ John Saunders: ¿Cómo es esto un posible duplicado? El otro tipo aparentemente sabe lo que es REST mientras que Nathan, por otro lado, está confundido.
Fake Code Monkey Rashid
Sentí que el otro respondería su pregunta. Si nadie más está de acuerdo, la votación cerrada desaparecerá. Tenemos alrededor de diez respuestas a esta pregunta. Simplemente haga clic en la etiqueta "descanso" y los verá a todos.
John Saunders
1
REST es un conjunto de reglas para construir servicios web. Si una API se construye de acuerdo con esas reglas, es una API REST. Cómo le expliqué REST a mi pato de goma explica algunas de esas reglas de manera informal.
Usuario42
Respuestas:
127
REST no es un servicio web específico, sino un concepto de diseño (arquitectura) para administrar la información del estado. El documento fundamental sobre esto fue la disertación de Roy Thomas Fielding (2000), "Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red" ( disponible en línea en la Universidad de California, Irvine).
Primero lea la publicación de Ryan Tomayko Cómo le expliqué REST a mi esposa ; Es un gran punto de partida. Luego lea la tesis real de Fielding. ¡No es tan avanzado, ni es largo (seis capítulos, 180 páginas)! (Sé que ustedes niños en la escuela les gusta poco).
EDITAR: Siento que no tiene sentido tratar de explicar REST. Tiene tantos conceptos como escalabilidad, visibilidad (sin estado), etc., que el lector necesita comprender, y la mejor fuente para comprenderlos es la disertación real. Es mucho más que POST / GET, etc.
@Nathan, confía en mí, tuve el mismo problema que tú antes. Lea la tesis, quizás repítala un par de veces lentamente, pero comprenderá el concepto, en realidad no es nada difícil. La gente simplemente tiende a explicarlo mal.
Anders
Cuando los desarrolladores tratan de emplear a descansar, y trate de hacerlo sólo en su código (sin planificación de todo el sistema con el descanso en mente), el infierno viene :-)
karatedog
@Anders, considerando que REST es lo que es, ¿cómo se puede comparar REST con los servicios web?
REST es un patrón de diseño de software que generalmente se usa para aplicaciones web. En términos simples, esto significa que es una idea de uso común utilizada en muchos proyectos diferentes. Significa REpresentational State Transfer . La idea básica de REST es tratar los objetos del lado del servidor (como en las filas de una tabla de base de datos) como recursos que se pueden crear o destruir.
La forma más básica de pensar en REST es como formatear las URL de sus aplicaciones web. Por ejemplo, si su recurso se llamaba "publicaciones", entonces:
/posts Sería cómo un usuario accedería a TODAS las publicaciones, para mostrar.
/posts/:id Sería cómo un usuario accedería y vería una publicación individual, recuperada en función de su identificación única.
/posts/new Sería cómo mostrarías un formulario para crear una nueva publicación.
Enviando una solicitud POST para /userssería cómo usted realmente crear una nueva entrada en el nivel de base de datos.
Enviar una solicitud PUT a /users/:idsería cómo actualizaría los atributos de una publicación determinada, nuevamente identificada por una identificación única.
Enviar una solicitud DELETE a /users/:idsería cómo eliminaría una publicación determinada, nuevamente identificada por una identificación única.
Según tengo entendido, el patrón REST se popularizó principalmente (para aplicaciones web) por el marco Ruby on Rails, que pone un gran énfasis en las rutas RESTful. Aunque podría estar equivocado sobre eso.
Puede que no sea el más calificado para hablar de ello, pero así es como lo aprendí (específicamente para el desarrollo de Rails).
Cuando alguien se refiere a una "API REST", generalmente lo que quieren decir es una API que utiliza URL RESTful para recuperar datos.
Tienes suerte, porque Rails se basa en los principios REST y si usas las herramientas de Rails, tu código será RESTful. Sin embargo, hay codificadores que no entienden Jack sobre REST, codifican lo que quieren y al final utilizan este 'formato de URL' porque está de moda.
karatedog
8
donde alguna vez se ha utilizado / users en esta respuesta, ¿no debería ser / posts?
Mayuresh Srivastava
@MayureshSrivastava Observe que los ejemplos PUT tienen: id y los ejemplos POST no tienen: id. Google para el resto de la historia. (POST: no seguro, no idempotente; PUT: no seguro, idempotente)
Ajeet Ganga
38
RESTes un estilo arquitectónico y un diseño para arquitecturas de software basadas en red.
RESTLos conceptos se denominan recursos. Una representación de un recurso debe ser apátrida. Se representa a través de algún tipo de medio. Algunos ejemplos de tipos de medios incluyen XML, JSON, y RDF. Los recursos son manipulados por componentes. Los componentes solicitan y manipulan recursos a través de una interfaz uniforme estándar. En el caso de HTTP, esta interfaz se compone de ops HTTP estándar por ejemplo GET, PUT, POST, DELETE.
RESTnormalmente se usa HTTP, principalmente debido a la simplicidad de HTTP y su mapeo muy natural a los principios RESTful. REST, sin embargo, no está vinculado a ningún protocolo específico.
Principios fundamentales de REST
Comunicación cliente-servidor
Las arquitecturas cliente-servidor tienen una separación muy clara de preocupaciones. Todas las aplicaciones creadas en el estilo RESTful también deben ser, en principio, cliente-servidor.
Apátrida
Cada solicitud de cliente al servidor requiere que su estado esté totalmente representado. El servidor debe poder comprender completamente la solicitud del cliente sin utilizar ningún contexto de servidor o estado de sesión del servidor. Se deduce que todo el estado debe mantenerse en el cliente. Discutiremos la representación sin estado con más detalle más adelante.
Caché
Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como almacenables en caché o no almacenables en caché. Cualquier dato marcado como almacenable en caché puede reutilizarse como respuesta a la misma solicitud posterior.
Interfaz uniforme
Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que toda la interacción de componentes se produce a través de esta interfaz, la interacción con diferentes servicios es muy simple. ¡La interfaz es la misma! Esto también significa que los cambios de implementación se pueden hacer de forma aislada. Dichos cambios no afectarán la interacción del componente fundamental porque la interfaz uniforme siempre no cambia. Una desventaja es que estás atrapado con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. En el lado positivo, sin embargo, REST está optimizado para la web, por lo tanto, ¡increíble popularidad de REST sobre HTTP!
Los conceptos anteriores representan características definitorias de REST y diferencian la arquitectura REST de otras arquitecturas como los servicios web. Es útil tener en cuenta que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.
Significa Representational State Transfer y puede significar muchas cosas, pero generalmente cuando habla de API y aplicaciones, habla de REST como una forma de hacer servicios web u obtener programas para hablar en la web.
REST es básicamente una forma de comunicarse entre sistemas y hace mucho de lo que SOAP RPC fue diseñado para hacer, pero mientras SOAP generalmente hace una conexión, se autentica y luego hace cosas a través de esa conexión, REST funciona de la misma manera que funciona la web . Tienes una URL y cuando solicitas esa URL obtienes algo de vuelta. Aquí es donde las cosas comienzan a ser confusas porque las personas describen la web como la aplicación REST más grande y, aunque esto es técnicamente correcto, en realidad no ayuda a explicar qué es.
En pocas palabras, REST le permite obtener dos aplicaciones hablando por Internet utilizando herramientas que son similares a las que usa un navegador web. Esto es mucho más simple que SOAP y mucho de lo que REST hace es decir: "Oye, las cosas no tienen que ser tan complejas".
REST es una arquitectura basada en restricciones, SOAP es un protocolo, esas son cosas completamente diferentes. No me gusta cuando la gente habla de SOAP y REST en el mismo concepto, no es de extrañar que la gente se confunda al respecto.
Anders
@Anders - Dijo que estaba mirando una API REST y pensó que era una forma de usar los servicios web. Puede usar REST así y en esa capacidad logra mucho de lo que SOAP logra. También es posible hablar de la web como la aplicación RESTful más grande del mundo, pero eso realmente no explica para qué usaría una API REST.
Mark
Este ha sido mi problema principal, ver REST y SOAP en el mismo concepto. Parece que las API son simplemente RESTful en diseño.
La idea básica es que, en lugar de tener una conexión continua con el servidor, realiza una solicitud, obtiene algunos datos, se los muestra a un usuario, pero tal vez no todos, y luego cuando el usuario hace algo que requiere más datos, o para pasar algo al servidor, el cliente inicia un cambio a un nuevo estado.
Tal vez soy solo yo, pero me gusta ver la respuesta relevante en stackoverflow junto con la cita apropiada. Solo humoréame y supongamos que Wikipedia se ha vuelto loca. ¿De qué sirve tu enlace entonces hmm? :)
Fake Code Monkey Rashid
1
@Hack Saw: ¿No debería estar eso en tu respuesta?
Fake Code Monkey Rashid
Acabo de notar la función de edición. :)
Hack Saw
1
@karatedog: REST se puede lograr con HTTP, pero se puede hacer con una variedad de métodos de transferencia de datos.
Hack Saw
1
Este es el protocolo HTTP sobre el que está escribiendo, REST es una arquitectura.
Respuestas:
REST no es un servicio web específico, sino un concepto de diseño (arquitectura) para administrar la información del estado. El documento fundamental sobre esto fue la disertación de Roy Thomas Fielding (2000), "Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red" ( disponible en línea en la Universidad de California, Irvine).
Primero lea la publicación de Ryan Tomayko Cómo le expliqué REST a mi esposa ; Es un gran punto de partida. Luego lea la tesis real de Fielding. ¡No es tan avanzado, ni es largo (seis capítulos, 180 páginas)! (Sé que ustedes niños en la escuela les gusta poco).
EDITAR: Siento que no tiene sentido tratar de explicar REST. Tiene tantos conceptos como escalabilidad, visibilidad (sin estado), etc., que el lector necesita comprender, y la mejor fuente para comprenderlos es la disertación real. Es mucho más que POST / GET, etc.
fuente
REST es un patrón de diseño de software que generalmente se usa para aplicaciones web. En términos simples, esto significa que es una idea de uso común utilizada en muchos proyectos diferentes. Significa REpresentational State Transfer . La idea básica de REST es tratar los objetos del lado del servidor (como en las filas de una tabla de base de datos) como recursos que se pueden crear o destruir.
La forma más básica de pensar en REST es como formatear las URL de sus aplicaciones web. Por ejemplo, si su recurso se llamaba "publicaciones", entonces:
/postsSería cómo un usuario accedería a TODAS las publicaciones, para mostrar./posts/:idSería cómo un usuario accedería y vería una publicación individual, recuperada en función de su identificación única./posts/newSería cómo mostrarías un formulario para crear una nueva publicación.Enviando una solicitud POST para
/userssería cómo usted realmente crear una nueva entrada en el nivel de base de datos.Enviar una solicitud PUT a
/users/:idsería cómo actualizaría los atributos de una publicación determinada, nuevamente identificada por una identificación única.Enviar una solicitud DELETE a
/users/:idsería cómo eliminaría una publicación determinada, nuevamente identificada por una identificación única.Según tengo entendido, el patrón REST se popularizó principalmente (para aplicaciones web) por el marco Ruby on Rails, que pone un gran énfasis en las rutas RESTful. Aunque podría estar equivocado sobre eso.
Puede que no sea el más calificado para hablar de ello, pero así es como lo aprendí (específicamente para el desarrollo de Rails).
Cuando alguien se refiere a una "API REST", generalmente lo que quieren decir es una API que utiliza URL RESTful para recuperar datos.
fuente
RESTes un estilo arquitectónico y un diseño para arquitecturas de software basadas en red.RESTLos conceptos se denominan recursos. Una representación de un recurso debe ser apátrida. Se representa a través de algún tipo de medio. Algunos ejemplos de tipos de medios incluyenXML,JSON, yRDF. Los recursos son manipulados por componentes. Los componentes solicitan y manipulan recursos a través de una interfaz uniforme estándar. En el caso de HTTP, esta interfaz se compone de ops HTTP estándar por ejemploGET,PUT,POST,DELETE.RESTnormalmente se usaHTTP, principalmente debido a la simplicidad de HTTP y su mapeo muy natural a los principios RESTful. REST, sin embargo, no está vinculado a ningún protocolo específico.Principios fundamentales de REST
Comunicación cliente-servidor
Las arquitecturas cliente-servidor tienen una separación muy clara de preocupaciones. Todas las aplicaciones creadas en el estilo RESTful también deben ser, en principio, cliente-servidor.
Apátrida
Cada solicitud de cliente al servidor requiere que su estado esté totalmente representado. El servidor debe poder comprender completamente la solicitud del cliente sin utilizar ningún contexto de servidor o estado de sesión del servidor. Se deduce que todo el estado debe mantenerse en el cliente. Discutiremos la representación sin estado con más detalle más adelante.
Caché
Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como almacenables en caché o no almacenables en caché. Cualquier dato marcado como almacenable en caché puede reutilizarse como respuesta a la misma solicitud posterior.
Interfaz uniforme
Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que toda la interacción de componentes se produce a través de esta interfaz, la interacción con diferentes servicios es muy simple. ¡La interfaz es la misma! Esto también significa que los cambios de implementación se pueden hacer de forma aislada. Dichos cambios no afectarán la interacción del componente fundamental porque la interfaz uniforme siempre no cambia. Una desventaja es que estás atrapado con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. En el lado positivo, sin embargo, REST está optimizado para la web, por lo tanto, ¡increíble popularidad de REST sobre HTTP!
Los conceptos anteriores representan características definitorias de REST y diferencian la arquitectura REST de otras arquitecturas como los servicios web. Es útil tener en cuenta que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.
Ver este blog después de Directores de diseño del resto para más detalles sobre REST y los principios anteriores.
fuente
Significa Representational State Transfer y puede significar muchas cosas, pero generalmente cuando habla de API y aplicaciones, habla de REST como una forma de hacer servicios web u obtener programas para hablar en la web.
REST es básicamente una forma de comunicarse entre sistemas y hace mucho de lo que SOAP RPC fue diseñado para hacer, pero mientras SOAP generalmente hace una conexión, se autentica y luego hace cosas a través de esa conexión, REST funciona de la misma manera que funciona la web . Tienes una URL y cuando solicitas esa URL obtienes algo de vuelta. Aquí es donde las cosas comienzan a ser confusas porque las personas describen la web como la aplicación REST más grande y, aunque esto es técnicamente correcto, en realidad no ayuda a explicar qué es.
En pocas palabras, REST le permite obtener dos aplicaciones hablando por Internet utilizando herramientas que son similares a las que usa un navegador web. Esto es mucho más simple que SOAP y mucho de lo que REST hace es decir: "Oye, las cosas no tienen que ser tan complejas".
Vale la pena leer:
fuente
http://en.wikipedia.org/wiki/Representational_State_Transfer
La idea básica es que, en lugar de tener una conexión continua con el servidor, realiza una solicitud, obtiene algunos datos, se los muestra a un usuario, pero tal vez no todos, y luego cuando el usuario hace algo que requiere más datos, o para pasar algo al servidor, el cliente inicia un cambio a un nuevo estado.
fuente