rest_api的安全设计

1、首先得考虑版本的设置,以便后续版本升级:

CREATIVE_URL="http://www.test.com/api/v1/creative/update"

使用post请求。

2、为用户调用提供唯一SALE验证:

SALT = "43545hhd11778916117435e49b1c31"

3、对SALT+body内容加密安全验证

sig = Digest::SHA1.hexdigest(SALT+"#{http_body_data.to_json}")

4、加上时间请求超时验证

The unix timestamp of current time;例如:确保服务器所在地时间和服务请求所在时间差值不大于10

5、添加每次请求唯一性验证

每次post请求时要求传送一个唯一随机字段。

等等。。。。

另外引用一下api设置原则:

API 的设计原则:转载

1.        用户导向的API(Application Programming Interface) 设计
API设计和UI设计实际上是一回事情,只是不同的用户对象而已。实际上他们做的是同一件事情,都是告诉机器,你应该给我做什么事情。API永远不是为自己设计的,设计API的时候,首先应该考虑的问题是,我这个API是给谁做?他们的背景是什么?他们会怎么用?要根据他们不同的需求去设计,要想清楚你究竟是为谁在做。

2.        封装(Encapsulation), 困难留给自己,方便留给用户
API是为了解决一个或一类问题,或提供一个或一类服务。其背后一定有一个或多个实现。设计API必须保证问题得到正确解决,服务得到合适提供。不能因为实现的困难,而改变API的设计,让使用者来承担困难,解决困难。困难解决得越多,API的价值越大。一个好的API,就是要把困难留给自己,方便留给用户。就是要让客户用起来方便,不需要再去解决这些问题,这是API最大的价值。

3.  简单懂易, self explain
好的API是简单易用的,好的API时不宜让用户犯错的。每个名字,每个签名都要做到简单易懂,不能模棱两可,更不能挂羊头卖狗肉。每个名字和签名不要用缩写,即使这些缩写是我们熟悉的行业标准,要想到可能用户并不熟悉我们的行业,新员工也会有学习成本,而我们仅仅是少打几个字而已。从小处做起。

4. 不可枚举,必须抽象
API是为了解决一个或一类问题,或提供一个或一类服务。对于同一类问题,不同的应用,不同的客户需求会有不同,问题的表现也可能不同。API不能因为这些不同,来枚举这些不同,一一解决,这是永远加不完的。 必需看到问题的本质,抽象解决,统一解决。

5. 服务分类, 各司其职,包得愈紧愈好,知道愈少愈好
形象的讲,在家里,该放到厨房的东西,放到厨房;该放到卧房的东西,放到卧房;该放到客厅的东西,放到客厅。在家里,你不会把这些东西混着乱放吧。那么,也不要把一个API变成了一个大杂烩。

你可能感兴趣的:(REST)