Resumen ejecutivo del Informe Global sobre Amenazas 2026 de CrowdStrike: el informe definitivo sobre inteligencia de amenazas para la era de la IA Descargar

Transforma el SOC con SIEM de nueva generación

Descubre el futuro de la tecnología SIEM. Mejora tu centro de operaciones de seguridad con automatización y estrategias SIEM de vanguardia.

Descarga tu guía ya

Transforma el SOC con SIEM de nueva generación

Descubre el futuro de la tecnología SIEM. Mejora tu centro de operaciones de seguridad con automatización y estrategias SIEM de vanguardia.

Descarga tu guía ya

La transferencia de estado representacional o REST (del inglés REpresentational State Transfer) es un estilo de arquitectura que permite crear API que se comunican a través del protocolo HTTP.

Para funcionar, las API necesitan a menudo manipular datos en segundo plano. Por lo general, estas operaciones de datos, conocidas como CRUD, se ejecutan en bases de datos backend. CRUD es el acrónimo de Create (crear), Read (leer), Update (actualizar) y Delete (eliminar), que conforman estas cuatro operaciones fundamentales.

Puesto que las llamadas a las API REST invocan operaciones CRUD, comprender la relación entre ambas es importante para los desarrolladores de API y los ingenieros de datos. Aunque CRUD y REST tienen objetivos distintos, el uso de uno no debería influir negativamente en el rendimiento del otro.

En este artículo, presentaremos CRUD y REST, explicaremos sus similitudes y diferencias, y analizaremos la mejor forma de monitorizar su rendimiento.

¿Qué es CRUD?

Las operaciones CRUD se aplican a los sistemas de gestión de bases de datos relacionales tradicionales, como PostgreSQL o SQL Server, y las bases de datos NoSQL más recientes, como MongoDB o DynamoDB. Aunque las operaciones dirigidas a archivos también gestionan la manipulación de información, CRUD hace generalmente referencia a las operaciones dirigidas a registros en bases de datos de computación.

En los sistemas de gestión de bases de datos relacionales (RDBMS), a una fila de una tabla de base de datos se le denomina registro, mientras que a las columnas se les denominan atributos o campos. Veamos las cuatro operaciones CRUD de forma individual.

Crear

La operación de crear añade un nuevo registro de base de datos. El equivalente en SQL para esta operación es INSERT.

Leer

Una operación de lectura recupera registros (o documentos o elementos, en función del tipo de base de datos) de una tabla de base de datos (o recopilación) en función de los criterios de búsqueda. El equivalente en SQL de una operación de lectura es SELECT. Las operaciones de lectura pueden devolver un subconjunto de registros y campos en función de la consulta.

Actualizar

Una operación de actualización, conocida como UPDATE en SQL, modifica los registros existentes en una base de datos. Una operación de actualización, al igual que sucede con la operación de lectura, puede afectar a todos los registros y/o campos o a un subconjunto de estos.

Eliminar

Una operación de eliminación, conocida como DELETE en SQL, elimina uno o varios registros de la base de datos.

En las bases de datos NoSQL, las expresiones que corresponden a las operaciones CRUD dependen de la plataforma, las estructuras de datos y el lenguaje. Por ejemplo, en MongoDB:

  • Una operación de creación utiliza db.collection.insertOne() o db.collection.insertMany().
  • Una operación de lectura utiliza db.collection.find() o db.collection.findOne().
  • Una operación de actualización utiliza db.collection.updateOne(), db.collection.updateMany() o db.collection.replaceOne().
  • Una operación de eliminación utiliza db.collection.deleteOne() o db.collection.deleteMany().

Por lo general, el código de la aplicación API realiza operaciones CRUD mediante la invocación de procedimientos, funciones o activadores almacenados en el RDBMS. En ocasiones, el código API también puede enviar comandos SQL generados dinámicamente al motor de la base de datos.

En las bases de datos NoSQL, el código de la aplicación API envía los comandos a través del controlador de la base de datos. Por ejemplo, una aplicación Java puede realizar una llamada a la biblioteca de controladores HBase para enviar comandos CRUD a la base de datos. En segundo plano, el controlador traducirá los comandos de Java y los ejecutará en la base de datos.

Ejemplo real de CRUD

Veamos un caso real de CRUD en acción. Cuando un usuario hace una reserva a través de una aplicación de servicios de viajes online, la aplicación crea un registro de la reserva, lee la información disponible sobre hoteles y habitaciones, actualiza la lista de habitaciones disponibles cuando se confirma la reserva o elimina el registro de reserva completo si el usuario cancela la solicitud. En cualquier aplicación de procesamiento de transacciones se producen operaciones similares.

¿Qué es REST?

REST es un estilo de arquitectura para API que suele utilizarse en aplicaciones distribuidas. Las API REST (o RESTful) son aplicaciones que se adhieren a los principios de arquitectura REST y permiten a las aplicaciones cliente y a otras API interactuar con ellas a través de sus endpoints de API. Las aplicaciones que acceden a API RESTful suelen enviar sus solicitudes mediante métodos de protocolo HTTP. Las seis principales restricciones de REST son:

  1. Interfaz uniforme: la interfaz uniforme permite que cualquier cliente de API se comunique con el servidor de forma coherente y estandarizada, independientemente del lenguaje de programación o la implementación del servidor o del cliente.
  2. Cliente-servidor: el patrón de diseño cliente-servidor atribuye funciones independientes al cliente y al servidor de la API. El servidor se responsabiliza del funcionamiento backend, como el almacenamiento de datos, la validación y la autenticación. Por su parte, el cliente se ocupa de la interfaz de usuario o la creación de consultas, entre otros.
  3. Sin estado: para que no tenga estado, cada solicitud de cliente a la API debe contener toda la información necesaria para que el servidor lleve a cabo la tarea. El servidor no guarda ninguna información del estado de la sesión, del cliente ni del servidor. En cuanto a la API, cada solicitud de cliente es nueva e independiente de la solicitud anterior.
  4. Almacenable en caché: esta restricción dictamina que la respuesta de la API se encarga de determinar si el cliente puede guardar en caché la respuesta de la API. La API marca la respuesta como almacenable o no almacenable en caché.
  5. Sistema en capas: las capas hacen referencia a la inclusión de componentes opcionales que proporcionan una funcionalidad, como el equilibrio de capas o la validación, entre otros. Estas capas deben ser transparentes para el cliente. Los componentes de cada capa solo deberían tener acceso a la capa con la que están trabajando.
  6. Código bajo demanda (opcional): el código bajo demanda permite a los clientes descargar y ejecutar código desde el servidor API.

Las API REST prevalecen en las aplicaciones modernas. Por ejemplo, las API meteorológicas, los servicios de streaming de vídeo, las redes sociales o las aplicaciones de viajes compartidos hacen un uso extensivo de las API REST.

Métodos HTTP

Los clientes envuelven las solicitudes de API RESTful con métodos HTTP:

  • GET: la solicitud GET pide a la API que recupere un recurso, como un registro de base de datos o los contenidos de un archivo, y que lo envíe al cliente.
  • POST: con el método POST, el cliente envía datos al servidor API, que crea un recurso con los datos suministrados.
  • PUT: cuando el cliente envía una solicitud PUT a la API, apunta a la URI de un recurso específico y proporciona datos en el cuerpo de la solicitud. Cuando el servidor API recibe la solicitud PUT, comprueba si el recurso ya existe. Si existe, la API actualiza el recurso con los datos incluidos en la solicitud PUT. Si no existe, la API crea el recurso con los datos proporcionados.
  • PATCH: el cliente envía una solicitud PATCH a la API para actualizar parcialmente un recurso existente.
  • DELETE: el cliente envía una solicitud DELETE a una API para borrar un recurso existente.

Ejemplo de solicitudes API REST

Existen varias herramientas de cliente que pueden enviar solicitudes a endpoints de API. Una línea de comando común es cURL. A continuación encontrarás varios ejemplos de uso de cURL para enviar solicitudes HTTP a un endpoint de API REST ficticio.

El endpoint final para nuestra API REST ficticia es http://www.foobar.com, y vamos a enviar varias solicitudes HTTP a la API para crear, leer, actualizar o eliminar registros personalizados.

En el siguiente fragmento de código, el cliente cURL solicita información de un cliente con el ID 19. Esta es una solicitud GET.

curl -v http://www.foobar.com/find_customert_record?id=19

A continuación, añadimos un registro de cliente con una solicitud POST. En el siguiente ejemplo de comando, añadimos los datos al cuerpo de la solicitud HTTP.

curl -X POST -d 'id=10&customer_name=joe_bloggs' http://www.foobar.com/add_customer_record

En este ejemplo, indicamos un archivo que contiene los datos para crear el registro.

curl -X POST -d @customer_record.json -H "Content-Type: application/json" http://www.foobar.com/add_customer_record

Para actualizar el registro del cliente, enviamos las siguientes solicitudes PUT.

curl -d 'id=10&client_name=jane_bloggs' -X PUT http://www.foobar.com/update_customer_record

Por último, eliminamos el cliente con el ID 22:

curl -X DELETE http://www.foobar.com/delete_customer_record?id=22

Comparación de CRUD y REST: similitudes y diferencias

Como ves, a pesar de sus diferencias, las operaciones API RESTful pueden ser muy similares a las operaciones CRUD de base de datos.

En el ejemplo de la aplicación de servicios de viaje mencionado anteriormente, una aplicación web inicia las operaciones de crear, leer, actualizar y eliminar. El sitio web frontend hará llamadas de API REST y el código API traducirá las solicitudes a comandos CRUD de base de datos y los enviará al controlador de la base de datos. Cuando el controlador de la base de datos devuelva una respuesta (correcta o incorrecta), el código API la traducirá a una respuesta HTTP y la enviará al cliente.

Para REST y CRUD, se envía una respuesta a la parte solicitante. Para clientes API REST, eso se produce en forma de respuesta HTTP estándar (por ejemplo, 200 OK, 404 Recurso no encontrado o 500 Error de servidor interno). Para CRUD, cada motor de base de datos tendrá sus propios códigos de respuesta para procesos que se realizan correctamente, dan error o muestran advertencias.

Veamos ahora las diferencias.

Ya hemos mencionado como CRUD y REST funcionan en diferentes partes de una pila de aplicaciones. Las API REST reciben sus payloads a través del protocolo HTTP, mientras que CRUD emplea cualquier protocolo que se haya activado en la base de datos. Los paquetes de red tienen también estructuras diferentes. Normalmente, API REST acepta solicitudes de cliente a través de los puertos 80o 443, aunque se pueden configurar. En las operaciones CRUD, por su parte, es la configuración del servidor de base de datos la que determina el puerto. Por ejemplo, el puerto predeterminado para SQL Server es 1433.

Las funciones CRUD pueden existir dentro del código API REST. No obstante, las API REST no se limitan a invocar operaciones CRUD. También pueden invocar otras funciones, subrutinas e incluso otras API.

Si bien existen innumerables API REST (públicas y privadas), el número de motores de bases de datos (como RDBMS, NoSQL y bases de datos en memoria) es limitado hoy en día.

Descubre la plataforma con IA nativa líder del mundo para SIEM de nueva generación y gestión de logs

Mejora tu ciberseguridad con CrowdStrike Falcon®, la principal plataforma nativa de IA para SIEM y gestión de logs. Disfruta de un registro de seguridad a escala de petabytes, con opciones de implementación nativas de la nube o de autoalojamiento. Registra tus datos con una arquitectura potente, sin índices y sin cuellos de botella, que hace posible el Threat Hunting con más de 1 PB de ingesta de datos al día. Disfruta de capacidades de búsqueda en tiempo real para superar al adversario y lograr una latencia inferior a un segundo en consultas complejas. Aprovecha una visibilidad integral que consolida los datos para acabar con los silos y permitir a los equipos de seguridad, TI y DevOps detectar amenazas, monitorizar el rendimiento y garantizar el cumplimiento sin problemas en 3 mil millones de eventos en menos de 1 segundo.

Arfan Sharif ocupa el cargo de Product Marketing Lead para la cartera de observabilidad en CrowdStrike. Ha dedicado más de 15 años al fomento de soluciones de gestión de logs, ITOps, observabilidad, seguridad y experiencia del cliente en empresas como Splunk, Genesys y Quest Software. Arfan se graduó en informática en la Universidad de Bucks and Chilterns y ha dedicado su carrera profesional al marketing de productos y la ingeniería de ventas.