Aprendí REST y se parece mucho a CRUD (por lo que he leído sobre CRUD).
Sé que son diferentes, y me pregunto si pensar que son similares significa que no los entiendo.
¿Es que REST es un "superconjunto" de CRUD? ¿Todo CRUD hace y más?
Aprendí REST y se parece mucho a CRUD (por lo que he leído sobre CRUD).
Sé que son diferentes, y me pregunto si pensar que son similares significa que no los entiendo.
¿Es que REST es un "superconjunto" de CRUD? ¿Todo CRUD hace y más?
Respuestas:
Sorprendentemente, no veo en las otras respuestas lo que considero la verdadera diferencia entre REST y CRUD: lo que cada uno maneja.
CRUD significa las operaciones básicas que se realizarán en un repositorio de datos. Usted maneja directamente registros u objetos de datos; Además de estas operaciones, los registros son entidades pasivas. Por lo general, solo se trata de tablas y registros de bases de datos.
REST, por otro lado, opera en representaciones de recursos, cada una identificada por una URL. Por lo general, no son objetos de datos, sino abstracciones de objetos complejos.
Por ejemplo, un recurso puede ser el comentario de un usuario. Eso significa no solo un registro en una tabla de 'comentarios', sino también sus relaciones con el recurso 'usuario', la publicación a la que se adjunta el comentario, tal vez otro comentario al que responde.
Operar en el comentario no es una operación de base de datos primitiva, puede tener efectos secundarios significativos, como disparar una alerta al póster original, o recalcular algunos 'puntos' similares a un juego, o actualizar algunos 'seguidores'.
Además, una representación de recursos incluye hipertexto (verifique el principio HATEOAS ), lo que le permite al diseñador expresar relaciones entre recursos o guiar al cliente REST en el flujo de trabajo de una operación.
En resumen, CRUD es un conjunto de operaciones primitivas (principalmente para bases de datos y almacenamientos de datos estáticos), mientras que REST es un estilo API de muy alto nivel (principalmente para servicios web y otros sistemas 'en vivo').
El primero manipula datos básicos, el otro interactúa con un sistema complejo.
En primer lugar, ambos son simplemente iniciales comunes; No hay nada de que temer.
Ahora, CRUD es un término simple que se abrevió porque es una característica común en muchas aplicaciones, y es más fácil decir CRUD . Describe las 4 operaciones básicas que puede realizar en datos (o un recurso). Crear, leer, actualizar, eliminar.
REST, sin embargo, es una práctica con nombre (al igual que AJAX), no una tecnología en sí misma. Fomenta el uso de capacidades que durante mucho tiempo han sido inherentes al protocolo HTTP, pero que rara vez se utilizan.
Cuando tienes una URL (Localizador Uniforme de Recursos ) y apuntas tu navegador por la línea de dirección, estás enviando una solicitud HTTP . Cada solicitud HTTP contiene información que el servidor puede usar para saber qué respuesta HTTP enviar al cliente que emitió la solicitud.
Cada solicitud contiene una URL, por lo que el servidor sabe a qué recurso desea acceder, pero también puede contener un método . Un método describe qué hacer con ese recurso.
Pero este concepto de "método" no se usaba muy a menudo.
Por lo general, las personas simplemente se vinculan a las páginas a través del método GET y emiten cualquier tipo de actualizaciones (eliminaciones, inserciones, actualizaciones) a través del método POST.
Y debido a eso, no se puede tratar un recurso (URL) como un verdadero recurso en sí mismo. Debía tener URL separadas para eliminar, insertar o actualizar el mismo recurso. Por ejemplo:
http://...com/posts/create- POST request -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request -> Goes to posts.edit(1) method in the server
Con REST, crea formularios que son más inteligentes porque usan otros métodos HTTP además de POST, y programa su servidor para poder distinguir entre métodos , no solo URLS. Así por ejemplo:
http://...com/posts - POST request -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request -> Goes to posts.edit(1) method in the server
Recuerde, una única URL describe un único recurso. Una sola publicación es un único recurso. Con REST, usted trata los recursos de la forma en que fueron tratados. Le está diciendo al servidor qué recurso desea manejar y cómo manejarlo.
Hay muchas otras características de la "arquitectura RESTful", sobre las que puede leer en Wikipedia, otros artículos o libros, si está interesado. Por otro lado, no hay mucho más para CRUD.
REST significa "transferencia de estado representacional", lo que significa que se trata de comunicar y modificar el estado de algún recurso en un sistema.
REST se involucra bastante, porque la teoría detrás de REST se centra en aprovechar los medios, los hipermedios y un protocolo subyacente para administrar la información en un sistema remoto.
CRUD, por otro lado, es un mnemotécnico para las operaciones comunes que necesita para los datos en una base de datos: Crear Recuperar Actualizar Eliminar. Pero realmente no hay nada más profundo que eso.
Esa es la respuesta a su pregunta, pero mencionaré el error común que veo cuando REST y CRUD se discuten juntos. Muchos desarrolladores desean asignar REST a CRUD directamente, porque REST sobre HTTP proporciona GET PUT POST y DELETE, mientras que CRUD proporciona CREATE RETRIEVE UPDATE DELETE. Es natural querer asignar los verbos REST directamente a las operaciones CRUD.
Sin embargo, HTTP utiliza un estilo de "crear o actualizar", mientras que CRUD separa crear y actualizar. Eso hace que sea imposible (!) Hacer un mapeo limpio y general entre los dos (!)
GET y DELETE son fáciles ... GET === RETRIEVE, y DELETE === DELETE.
Pero según la especificación HTTP, PUT es en realidad Crear Y Actualizar:
Use PUT para crear un nuevo objeto cuando sepa todo sobre él, incluido su identificador
Use PUT para actualizar un objeto (generalmente con una representación completa del objeto)
POST es el verbo "procesamiento", y se considera el verbo "agregar":
Use POST para agregar un nuevo objeto a una colección, es decir, crear un nuevo objeto
POST también se usa cuando ninguno de los otros verbos encaja bien, ya que la especificación HTTP lo define como el verbo "procesamiento de datos"
Si su equipo se está quedando colgado en POST, recuerde que todo el WWW se creó en GET y POST;)
Entonces, aunque hay similitud entre REST y CRUD, el error que veo que la mayoría de los equipos comete es hacer una equivalencia entre los dos. Un equipo realmente debe tener cuidado al definir una API REST para no obsesionarse demasiado con la mnemotecnia CRUD, porque REST como práctica realmente tiene mucha complejidad adicional que no se asigna de manera clara a CRUD.
CRUD especifica un conjunto mínimo de verbos de almacenamiento básicos para la lectura y escritura de datos: crear, leer, actualizar y eliminar. Luego, puede construir otras operaciones agregando estas. Por lo general, se consideran operaciones de base de datos, pero lo que se considera una base de datos es arbitrario (por ejemplo, podría ser un DBMS relacional, pero también podría ser archivos YAML).
REST es un "estilo arquitectónico" que generalmente incluye operaciones CRUD y otras operaciones de nivel superior, todo para ser realizado en algún concepto de "recursos" (arbitrario, pero estas son entidades en su aplicación). REST tiene un montón de restricciones que lo hacen interesante (y particularmente bien emparejado con HTTP).
Una interfaz REST puede, pero no tiene que exponer, todas las operaciones CRUD en un recurso en particular. Lo que está disponible en una interfaz REST es arbitrario y puede cambiar debido a los permisos del sistema, las consideraciones de la interfaz de usuario y lo caliente que estaba el día en que se diseñó y creó la interfaz. Los días más calurosos conducen a interfaces más minimalistas, por lo general, aunque lo contrario puede ser cierto.
CRUDO
DESCANSO
REST significa Transferencia de estado representacional (a veces se deletrea "ReST")
Se basa en un protocolo de comunicaciones apilable, cliente-servidor y sin estado, y en prácticamente todos los casos, se utiliza el protocolo HTTP
REST es un estilo de arquitectura para diseñar aplicaciones en red
REST es algo así como una página web para máquinas, que pueden navegar, mientras que CRUD es algo así como SOAP, que está fuertemente acoplado a sus clientes. Estas son las principales diferencias. De c. son similares en la superficie, pero CRUD describe la manipulación básica de entidades, mientras que REST puede describir la interfaz de cualquier aplicación. Otra diferencia es que REST puede usar más los 4 métodos HTTP. Sería una respuesta muy larga si quisiera recopilar todas las diferencias, si marca las preguntas sobre REST vs SOAP, encontrará la mayoría de ellas.
Creo que confundir REST con CRUD es un error muy común y la causa es que los desarrolladores no tienen tiempo para leer sobre REST en profundidad. Solo quieren usar la tecnología, sin entenderla, basada en ejemplos de estilo CRUD limitados escritos por desarrolladores similares. La gran mayoría de los ejemplos y tutoriales reflejan una grave falta de conocimiento. Asignar recursos REST a entidades y métodos HTTP a operaciones CRUD de estas entidades y usar REST sin hipervínculos es solo un síntoma de eso. Mediante REST, asigna los hipervínculos (incluidos los enlaces con los métodos POST / PUT / DELETE / PATCH) a sus operaciones e identifica la operación en el lado del cliente marcando la relación de enlace (generalmente específica de la API). Si un cliente REST no sabe qué es una relación de enlace y solo conoce los métodos HTTP y quizás algunas plantillas de URI, entonces ese no es un cliente REST, sino un CRUD en un cliente HTTP. Otro error común de que un cliente REST es una aplicación de JavaScript de una sola página que se ejecuta en el navegador. Por supuesto, puede implementar dicho cliente, pero REST estaba destinado principalmente a clientes automáticos (aplicaciones del lado del servidor escritas por desarrolladores que ni siquiera conoce) y no para clientes manuales (aplicaciones de navegador controladas por el usuario escritas por usted). Tener solo un cliente de navegador puede ser una señal de que realmente no necesita REST y simplemente ha modificado el proyecto. En estos casos, una API CRUD es una solución viable y los desarrolladores llaman a estas API CRUD como REST, porque no saben la diferencia. Por supuesto, puede implementar dicho cliente, pero REST estaba destinado principalmente a clientes automáticos (aplicaciones del lado del servidor escritas por desarrolladores que ni siquiera conoce) y no para clientes manuales (aplicaciones de navegador controladas por el usuario escritas por usted). Tener solo un cliente de navegador puede ser una señal de que realmente no necesita REST y simplemente ha modificado el proyecto. En estos casos, una API CRUD es una solución viable y los desarrolladores llaman a estas API CRUD como REST, porque no saben la diferencia. Por supuesto, puede implementar dicho cliente, pero REST estaba destinado principalmente a clientes automáticos (aplicaciones del lado del servidor escritas por desarrolladores que ni siquiera conoce) y no para clientes manuales (aplicaciones de navegador controladas por el usuario escritas por usted). Tener solo un cliente de navegador puede ser una señal de que realmente no necesita REST y simplemente ha modificado el proyecto. En estos casos, una API CRUD es una solución viable y los desarrolladores llaman a estas API CRUD como REST, porque no saben la diferencia.