Las API de escritura solían validar todos los parámetros de entrada en el lado de Java (o PHP, lo que sea), pero ahora movimos nuestras bases de datos a PostgreSQL, lo que nos brinda excelentes características de JSON, como construir JSON a partir de filas de tablas y mucho más (no lo hice). encontrar algo que no podamos sin las funciones JSON de PGSQL hasta ahora). Así que pensé, ¿qué pasa si hago la validación de todos los parámetros en Postgres (también teniendo en cuenta que puedo devolver JSON directamente desde la base de datos)?
En Java lo hice así:
if (!params.has("signature")) //params comes from @RequestBody casted to JSONObject return errGenerator.genErrorResponse("e01"); //this also need database access to get error descriptionEn un Postgres lo haré así (probado, funciona como se esperaba):
CREATE OR REPLACE FUNCTION test.testFunc(_object JSON) RETURNS TABLE(result JSON) AS $$ BEGIN IF (_object -> 'signature') IS NULL --so needed param is empty THEN RETURN QUERY (SELECT row_to_json(errors) FROM errors WHERE errcode = 'e01'); ELSE --everything is okay RETURN QUERY (SELECT row_to_json(other_table) FROM other_table); END IF; END; $$ LANGUAGE 'plpgsql';Y así...
El único problema que veo hasta ahora es que si pasamos a MS SQL o Sybase, será necesario volver a escribir todos los procedimientos. Pero a medida que NoSQL llega cada vez más, parece poco probable y si nos mudamos a NoSQL DB, también tendremos que recodificar todas las API.
Hay que tener en cuenta básicamente dos elementos:
Cuanto más cerca coloque sus cheques del almacenamiento de datos, más seguro será. Si hace que la base de datos realice todas las comprobaciones, se realizarán sin importar cómo interactúe con ella, ya sea a través de su aplicación o a través de alguna herramienta de terceros que pueda estar utilizando (aunque solo sea para mantenimiento). En ese sentido, la verificación en el lado de la base de datos mejora la seguridad (como en la "coherencia de datos"). En ese sentido, tiene todo el sentido que la base de datos realice las comprobaciones.
Cuanto más cerca coloque sus cheques del usuario, más rápido podrá responder a su entrada. Si tiene una aplicación web que necesita tiempos de respuesta rápidos , probablemente desee tener las comprobaciones en el lado del cliente .
Y toma en consideración una importante:
Puede tener una tercera forma: realice ambas comprobaciones en serie , primero en el lado de la aplicación (cliente), luego en el lado de la base de datos (servidor). A menos que tenga una automatización sofisticada, esto implica un trabajo adicional para asegurarse de que todas las comprobaciones realizadas sean coherentes. Es decir, no debería haber datos bloqueados en el lado del cliente que podrían pasar cuando la base de datos los verifique. Al menos, las comprobaciones más básicas se realizan en las primeras etapas, y todas ellas (incluso si son redundantes) se realizan en la base de datos.
Si puede permitirse el tiempo para mover los datos a través de varias capas de aplicaciones, iría con seguridad. Sin embargo, la elección a realizar es específica del caso.
Así que encontré algunas claves... La principal es que puedo hacer que mis mensajes de error se almacenen en caché en mi aplicación, lo que permitirá evitar realizar una solicitud de base de datos si los parámetros de entrada no los pasan y solo ir a la base de datos para obtener los datos del resultado.