diferencia entre REST y CRUD

Sorprendentemente, no veo en las otras respuestas lo que considero la diferencia real 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 los registros u objetos de datos; Aparte de estas operaciones, los registros son entidades pasivas. Normalmente, 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. Normalmente, estos no son objetos de datos, sino abstracciones de objetos complejos.

Por ejemplo, un recurso puede ser un 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, recalcular algunos 'puntos' similares a juegos, o actualizar algunos 'flujo de seguidores'.

Además, una representación de recursos incluye hipertexto (verifique el principio HATEOAS ), lo que permite al diseñador expresar relaciones entre los 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 almacenamiento de datos estáticos), mientras que REST es un estilo de API de muy alto nivel (principalmente para servicios web y otros sistemas 'en vivo').

El primero manipula los datos básicos, el otro interactúa con un sistema complejo.

En primer lugar, ambos son simplemente iniciales comunes; No son nada de lo que temer.

Ahora, CRUD es un término simple que se abrevia 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.

Sin embargo, REST, es una práctica con nombre (como 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 tiene una URL (Uniform Localizador de recursos ) y la apunta con su navegador por la línea de dirección, está enviando una solicitud HTTP . Cada solicitud HTTP contiene información que el servidor puede usar para saber qué respuesta HTTP se debe 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 solo enlazarían a las páginas a través del método GET y emitirían cualquier tipo de actualizaciones (eliminaciones, inserciones, actualizaciones) a través del método POST.

Y debido a eso, no pudo tratar un recurso (URL) como un verdadero recurso en sí mismo. Debía tener direcciones 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 aparte de POST, y programa su servidor para que pueda 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 sola URL describe un solo recurso. Una sola publicación es un solo recurso. Con REST, usted trata los recursos de la forma en que debían ser tratados. Le está diciendo al servidor qué recurso desea manejar y cómo manejarlo.

Hay muchas otras características de "arquitectura REST", que puedes leer en Wikipedia, otros artículos o libros, si estás interesado. No hay mucho más para CRUD en sí, por otra parte.

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 basa en el uso de medios, hipermedia 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 Eliminar Eliminar Actualización. Pero realmente no hay nada más profundo que eso.

Entonces 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 a través de 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 de CRUD.

Sin embargo, HTTP utiliza un estilo de "crear o actualizar", mientras que CRUD separa la creación y la actualización. Eso hace que sea imposible (!) Hacer un mapeo general y limpio entre los dos (!)

GET y DELETE son fáciles ... GET === RETRIEVE, y DELETE === DELETE.

Pero según la especificación de HTTP, PUT es en realidad Crear Y Actualizar:

• Use PUT para crear un objeto nuevo 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 "procesando" y se considera el verbo "agregar":

• Use POST para agregar un nuevo objeto a una colección, es decir, cree un nuevo objeto

• POST también se usa cuando ninguno de los otros verbos se ajusta bien, ya que la especificación HTTP lo define como el verbo de "procesamiento de datos"

• Si su equipo se está quedando colgado en POST, recuerde que todo el WWW se creó con GET y POST;)

Entonces, si bien existe una similitud entre REST y CRUD, el error que veo en la mayoría de los equipos es hacer una equivalencia entre los dos. Un equipo realmente debe tener cuidado al definir una API REST para no quedar demasiado obsesionado con la mnemotécnica CRUD, porque REST como práctica realmente tiene mucha complejidad adicional que no se relaciona de manera clara con CRUD.

CRUD especifica un conjunto mínimo de verbos básicos de almacenamiento para leer y escribir datos: crear, leer, actualizar y eliminar. Luego, puedes 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ían ser archivos YAML).

REST es un "estilo arquitectónico" que usualmente incluye operaciones CRUD y otras operaciones de nivel superior, todas realizadas 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 hacerlo, exponer todas las operaciones CRUD en un recurso particular. Lo que está disponible en una interfaz REST es arbitrario y puede cambiar debido a los permisos del sistema, a las consideraciones de la UI y al calor que tenía 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.

CRUD

• CRUD es 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 una que usa formularios para ingresar y salir datos de una base de datos

REST

• REST significa Transferencia de Estado Representacional (a veces se deletrea "ReST")

• Se basa en un protocolo de comunicaciones sin caché, cliente-servidor y con capacidad de almacenamiento en caché, 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 la entidad, 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 revisa las preguntas sobre REST vs SOAP y 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 en profundidad sobre REST. Solo quieren usar la tecnología, sin entenderla, en base a 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 las operaciones CRUD de estas entidades y usar REST sin hipervínculos es solo un síntoma de eso. Al 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 al verificar la relación del 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, no es un cliente REST, sino un CRUD en el cliente HTTP. Otro error común es que un cliente REST es una aplicación javascript de una sola página que se ejecuta en el navegador. Por supuesto, puede implementar dicho cliente, pero REST estaba destinado principalmente para 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 un solo cliente del navegador puede ser una señal de que realmente no necesita REST y que acaba de diseñar el proyecto. En estos casos, una API de CRUD es una solución viable y los desarrolladores llaman a estas API de CRUD como REST, porque no conocen la diferencia.