编写API我用来验证Java(或PHP,无论如何)方面的所有输入参数,但现在我们将DB移动到PostgreSQL,这为我们提供了很好的JSON功能,比如从表行构建JSON等等(I没有PGSQL JSON函数到目前为止我们找不到任何东西。所以我想如果我对Postgres进行所有参数验证(还考虑到我可以直接从数据库返回JSON)?
在Java中,我这样做了:
if (!params.has("signature"))
//params comes from @RequestBody casted to JSONObject
return errGenerator.genErrorResponse("e01"); //this also need database access to get error description
在Postgres上我会像这样(测试,按预期工作):
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';
等等......
到目前为止,我看到的一个问题是,如果我们转向MS SQL或Sybase,则需要重写所有过程。但是随着NoSQL现在越来越多,似乎不太可能。如果我们迁移到NoSQL DB,我们还必须重新编码所有API
答案 0 :(得分:4)
你必须考虑两件事:
您将支票越靠近数据存储,就越安全。如果您让数据库执行所有检查,无论您如何与它进行交互,无论是通过您的应用程序,还是通过您可能正在使用的某些第三方工具(如果仅用于维护),它们都将被执行。从这个意义上讲,在数据库端进行检查可以提高安全性(如“数据一致性”)。在这方面,让数据库执行检查确实很有意义。
您将支票越靠近用户,您可以以最快的速度回复他/她的输入。如果您的网络应用程序需要快速响应时间,您可能希望在客户端端进行检查。
并考虑一个重要的问题:
您可以采用第三种方式:同时进行系列检查,firts应用程序(客户端)端,然后是数据库(服务器端)。除非您有一些复杂的自动化,否则这需要额外的工作以确保所执行的所有检查都是一致的。也就是说,在数据库检查时,不应该在客户端阻止任何允许通过的数据。至少,最基本的检查是在第一阶段进行的,所有这些检查(即使它们都是冗余的)都是在数据库中执行的。
如果您有足够的时间将数据移动到多个应用程序层,我会安全地使用。但是,要做出的选择是针对特定情况的。
答案 1 :(得分:1)
所以我找到了一些密钥......主要的是我可以在我的应用程序中缓存我的错误消息,这样可以避免在输入参数没有通过它时只发送数据库到数据库请求获取结果数据