REST, transferencia de estado representacional, es un diseño de arquitectura creado por Roy Fielding, quien también co-diseñó el estándar HTTP. Define algunos conceptos específicos:
– el servidor del cliente, el servidor y el cliente no dependen el uno del otro
– sin estado, cada solicitud contiene toda la información necesaria para devolver una respuesta, como si está conectado
– almacenable en caché, los datos pueden almacenarse, lo que reduce la necesidad de solicitudes de servidor redundantes
– en capas, el cliente y el servidor pueden estar separados por un proxy, caché, etc.
– código bajo demanda, el servidor puede actualizar al cliente con una nueva funcionalidad
– interfaz uniforme, las URL de punto final están estandarizadas, no especializadas para AJAX, XML ni HTML
Transferencia de estado representacional
Lo que es notable es que ninguna de las API web más populares usa REST completo, son algo RESTful. Muchos desarrolladores confunden REST con ser URL legibles para humanos, por ejemplo: / blog / 2014/01/01 / Luego está el surgimiento de MVC, lo que lleva a muchos desarrolladores a crear diferentes URL para AJAX, ex / blog / 2014/01/01 / json y diferentes URL para versiones, por ejemplo: / v2 / blog / 2014/01/01 / xml Ninguno de estos es verdadero REST. Eso es lo básico, ahora cubriré los detalles de por qué cada uno es útil.
- ¿Qué empresas de aplicaciones web de Internet crearon su aplicación web con Ruby on Rails?
- ¿Cuál es un ejemplo de una aplicación Sinatra de código abierto que está bien organizada?
- ¿Cómo se escapa legalmente un motor de recomendación con el uso de imágenes de productos?
- ¿Hay algún ejemplo en el que solo se pueda usar el servicio web SOAP y no REST?
- ¿Cuáles son los ejemplos de pequeñas aplicaciones web o proyectos que los principiantes pueden hacer?
Cliente-servidor , esto permite una separación de preocupaciones, de modo que el servidor web no confía en que su navegador específico tenga una función, y su navegador no confía en el servidor web que utiliza una tecnología específica.
Sin estado , significa que el servidor web no necesita recordar los detalles de su navegador web o aplicación móvil. La solicitud de la página web que envíe, por ejemplo, incluirá un encabezado de cookie de sesión http, que le indicará al servidor que ha iniciado sesión. Esto significa que cada solicitud es autónoma y no se basa en un orden o secuencia específica.
Cachéable , le permite a usted o cualquier otro servidor almacenar en caché las solicitudes. Por ejemplo, si tiene una aplicación de correo electrónico que solicita una lista de todos sus contactos, esa es una cantidad moderada de datos que no cambiará con frecuencia, por lo que debe almacenarse en caché. En lugar de que el servidor consulte una base de datos, analice el contenido, lo formatee y lo devuelva, el resultado final se puede almacenar en caché en otro servidor o en su aplicación móvil, lo que simplifica enormemente la solicitud y la hace mucho más rápida.
En capas , es un buen efecto de implementar los conceptos mencionados anteriormente, permitiendo que la plataforma general se pueda construir y expandir fácilmente con herramientas como el almacenamiento en caché, la seguridad, etc.
Code on demand , es un concepto muy nuevo, permite expandir dinámicamente lo que puede hacer un sistema web. Las nuevas bibliotecas mvvc javascript del lado del cliente, como AngularJS, permiten esto. Básicamente, el sitio web es una página web singular, con JavaScript cargando y descargando contenido dinámicamente. Esto significa que hay una URL para una plantilla de publicación genérica, por ejemplo: / blog / post / y luego hay una URL AJAX JSON, por ejemplo: / blog / post / 2014/01/01 El javascript del lado del cliente tomará el JSON y renderice la plantilla genérica, todo en su navegador, en lugar de hacerlo en el servidor. Lo bueno de esto es que puedo mantener el contenido del blog AJAX JSON igual, pero cambiar la plantilla en el futuro.
Interfaz uniforme , significa usar una única URL para todas y cada una de las llamadas a una entrada de datos específica, como una sola publicación de blog. Una URL verdaderamente tranquila permite devolver html, json, xml, yaml u otro, definido por los encabezados de solicitud http que envía su navegador o aplicación móvil. He implementado esto en algunos sistemas ahora. Permite que un sitio web use la misma URL que una aplicación móvil. El sitio web javascript llamará / blog / post / 2014/01/01 y obtendrá html, mientras que una aplicación móvil también llamará / blog / post / 2014/01/01 y volverá a json. Dentro de la respuesta, el servidor también puede definir enlaces entre entradas de datos, como cuáles son las publicaciones de blog siguientes y anteriores, y varias plantillas. Esto lleva a HATEOAS.
REST es el estándar a seguir y es lo que casi todos los sistemas web usarán en los próximos años. En realidad, es mucho más fácil seguirlo y obtener resultados sorprendentes, en lugar de hacer atajos pirateados, ya que REST se basa en HTTP.
Campo de golf:
Modelo de madurez de Richardson
HATEOAS: una discusión de seguimiento sobre el descanso
Lleva tu API REST al siguiente nivel con HATEOAS
Los enemigos odiarán a HATEOAS
Esta semana en REST
