Pensando que son medios similares que no los entiendo. Al leer las respuestas, veo un nivel sorprendente y que considero incorrecto de no reconocer las similitudes entre los conceptos. Creo que la forma correcta de entender REST es pensarlo como "CRUD para recursos HTTP". Si comprende qué es un recurso HTTP (obviamente no es lo mismo que un registro de base de datos) y sabe qué es CRUD, entonces describir REST como "CRUD para recursos HTTP" es una forma correcta y sucinta de transmitir la esencia de REST.
Jason Livesay
Respuestas:
205
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.
@Javier Gracias por distinguirlos. Utilicé REST Learning Rails y tuve la impresión de que era un reemplazo para CRUD (del que aprendí desde ... el nombre, es decir, ya lo estaba usando, simplemente no sabía cómo llamarlo) ... Usted convirtió REST vs CRUD de comparar 2 manzanas a comparar manzanas y naranjas. Gracias
Jesse Black
2
@Maudicus: creo que es muy común, ya que RoR incluye una capa CRUD (como lo hace la mayoría (¿todos?)), Y hace que sea fácil (¿automático?) Agregar una API REST además de eso, es fácil pensar que es todo lo que es REST. Pero luego puede agregar funcionalidad sobre CRUD pero detrás de la API REST, haciéndolas cada vez más diferentes.
Javier
1
Su respuesta es correcta, pero el ejemplo no es óptimo: un comentario puede reducirse a una sola fila db, ¿y no es posible implementar cambios dinámicos en objetos relacionados con activadores db? Sin embargo, creo que hay algo más que operaciones groseras en una API relajante, y su respuesta claramente lleva esa sensación bien.
didierc
2
Entonces ... lo mismo, capa diferente :)
AlikElzin-kilaka
¡Muchas gracias por expresar esto! Agregaría que la limitación de los verbos HTTP a las operaciones CRUD resulta en la implementación de REST literalmente como CRUD, con muchas herramientas que generalizan el estándar CRUD y pierden un lugar para esta lógica personalizada de "operar en un comentario".
sompylasar
99
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.
lo siento, pero REST es mucho más que CRUD. principalmente porque los recursos contienen mucho más que un solo registro cada uno, y cada operación hace mucho más que actualizar un registro.
Javier
11
Okay. Estoy de acuerdo. ¿Por que lo sientes? No dije que no era mucho más que CRUD. Creo que eso es exactamente lo que me digo.
Yam Marcovic
44
Esta debería ser la respuesta correcta.
Brandon
La especificación HTML solo permite los métodos GET y POST para el envío de formularios, por lo que los otros métodos no se utilizaron en los servicios que manejan solicitudes de clientes web antes de que AJAX se generalizara. Algunos servicios usan un campo de entrada oculto con el nombre "_method" como solución alternativa para especificar un método distinto de POST mientras envían el formulario utilizando el método POST.
Kenneth Sundqvist
20
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.
Gracias Yar. Parece mi "¿Hace todo CRUD y más?" es un sí, con un tecnicismo de REST se aplica a más que solo entradas en una base de datos.
Jesse Black el
@Maudicus Actualicé la respuesta, pero para ser específicos: puede pero NO TIENE que hacerlo.
Dan Rosenstark
No diría que son necesarios para que su solicitud se considere completa. Algunas aplicaciones no necesitan inserciones, eliminaciones o actualizaciones, por naturaleza.
Yam Marcovic
@Yam Marcovic, está bien, ajustado
Dan Rosenstark
6
CRUDO
CRUD son cuatro tipos básicos de comandos SQL: Crear, Leer, Actualizar y Eliminar
La mayoría de las aplicaciones tienen algún tipo de funcionalidad CRUD
Una aplicación CRUD es aquella que utiliza formularios para ingresar y sacar datos de una base de datos.
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.
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.
fuente
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:
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:
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.
fuente
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.
fuente
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.
fuente
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
fuente
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.
fuente