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变成了一个大杂烩。