¿Qué es REST? Ligeramente confundido [cerrado]

Supuse que REST era un servicio web, pero parece que estoy equivocado al pensar esto, entonces, ¿qué es REST?

He leído Wikipedia pero aún no puedo entenderlo. ¿Por qué hacer muchos lugares se refieren a las API como API REST?

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.

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.

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.

Ver este blog después de Directores de diseño del resto para más detalles sobre REST y los principios anteriores.

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:

• Cómo le expliqué REST a mi esposa (ahora disponible aquí)
• Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red

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.