REST significa transferencia de estado representativa. Ahora veamos qué significa eso. Intentaré simplificarlo.
La premisa básica es esta: REST expone un conjunto de ‘recursos’ que pueden ser operados utilizando operaciones CRUD (crear, leer, actualizar y eliminar). Ahora, cuando solicita un ‘recurso’, puede solicitar una ‘representación’ específica del mismo. Entonces, si desea un SVG o JSON o HTML o XML o PDF, etc. La elección de la representación es del cliente, pero está restringida por lo que el servidor puede proporcionar. De ahí el concepto de ‘negociación de contenido’ (el cliente envía preferencias y el servidor actúa en consecuencia o envía una lista de lo que es aceptable, etc.)
Ahora, la ‘representación’ está en el lado del cliente. Así que he transferido el “estado de la aplicación” al cliente como una representación en esencia. Es decir, como servidor trato cada solicitud como si fuera nueva. No mantengo el estado. Es responsabilidad del cliente mantener eso. Por lo tanto, los estados en forma de representaciones se han transferido al cliente. Por lo tanto REST 🙂
- ¿Deberían ser los mismos requisitos del sistema, como CPU y RAM para los maestros y esclavos de Hadoop?
- ¿Qué hay de nuevo en la tecnología informática?
- ¿Cuáles son algunos proyectos simples de PNL basados en un documento de conferencia (no demasiado complejo) que un estudiante de informática puede probar? Necesito hacer un proyecto de compilador basado en PNL como parte de mi curso.
- ¿Cuál es el uso de la teoría del Grupo de Renormalización fuera de la física cuántica?
- ¿Es más probable que se desarrolle una IA fuerte mediante la fusión del cerebro con la tecnología que mediante la inteligencia artificial pura?
Entonces, ¿por qué es importante? Bueno, esta es una vista muy poderosa. ¡Puede transferir el mantenimiento del estado a los clientes! Los servidores pueden sobrevivir a los reinicios sin tener una lógica de reanudación de estado complejo en su lugar. Puedo tener muchos servidores tontos que podrían atender la solicitud y no preocuparse de quién estaba trabajando en ella ‘una solicitud antes’, por lo que obtienes una escalabilidad casi gratuita 🙂 (Nada es gratis pero entiendes el punto. Es más gratis que basado en la sesión gestión / diseño del servidor). Por supuesto, la solicitud de autenticación / autorización debe estar codificada en cada solicitud, pero eso es lo que debe hacer de todos modos ya que no siempre puede confiar en el cliente 🙂 (Pensaría que es más fácil hacerlo una vez y mantener una sesión, pero si algo sale mal o el servidor se reinicia, es un poco engorroso recuperar la sesión si fue ‘solo en la memoria’)
Ahora puede cambiar las sesiones a las bases de datos y está bien. Sus servidores aún pueden sobrevivir a un reinicio. Pero entonces el DB podría convertirse en un cuello de botella y ese es un problema completamente diferente. Echa un vistazo a: http://stackoverflow.com/questio…
Además HTTP está bastante bien diseñado. Puede aprovechar su implementación y ya se han enviado mensajes de error bien definidos, solo eche un vistazo a los códigos de respuesta / error de HTTP. No es necesario crear códigos / objetos de error personalizados. Es un ‘conector’ bien definido con una ‘interfaz’ bien definida.
Usted aprovecha directamente los verbos HTTP en lugar de crear métodos especiales get / set / delete, etc. Simplemente hace que sus aplicaciones sean MUCHO más fáciles de diseñar y mantener si sigue los estándares.
Si desea obtener más información, le sugiero Wikipedia: http://en.wikipedia.org/wiki/Rep… y el libro RESTful Web Services de Richardson & Ruby
