顶，我赞成这个意见！标准是经过很多实际的案例证明的，自己实现的如果场景较为单一问题还不大，如果环境发生变化就可能导致很多难以估计的问题

标准是历经了很多考验的，其中涉及也包含众多情况的思考；而自定标准的对象可能仅仅是我们眼前的这一切，还是有着思维局限性的。

赞楼主的第一帖。基本同意楼上的意见，补充两点：
1、自创不是不可以，你看所有现行标准不也都是从自创内容逐渐演变成标准么。不过建议要有大公司那种环境，这样可以早期就多做考验，避免考虑失衡；另外要开放，让其他人可以帮助完善你的私有标准，这些都是为了解决更多接受现实考验的问题。
2、推荐使用标准的还一个原因是，即使出现问题，标准也会更快的出现通用的解决方案（例如http-》https），解决之比私有内容自己查找思考要花费的成本相对较低。

@GaRY @牛奶坦克 @xsser 先多谢各位的解答，其实大家的意见都比较一致，就是应该尽可能的遵循广泛实践的标准，即所谓“don’t roll your own”。但是有些时候如果碰到场景限制的时候，得自创标准时，新的注意点除了场景，还有哪里？我贴出的文章草稿其实是想用这样的一个现实案例来说明遵循和自创的两难：

一个通用建站程序需要开发一个用户注册的手机API（/api_mobile/user/login），初期设计如下：业界事实标准的HTTP API通讯方式；HTTP POST；参数email，password，login_type。请求包如下：

POST /api_mobile/user/login HTTP/1.1
……
email=aaa@aaa.com&password=123456&login_type=1&appkey=123456&api_ver=1&timestamp=11111111&sign=23rasfas

则此时由于http协议固有的明文传输，在钓鱼wifi下就会遭遇信息泄露的问题（wooyun已有相关案例）。

如果沿着遵循标准的思路来讲，最好的机制当然上https（先不考虑“万能证书”的威胁）。但很可惜的是，通用建站程序在这个步骤上存在着场景限制而不能执行——不可能要求每个站长都可以申请到可信证书。于是乎有人想到加密敏感参数再传输：
enc_data=加密方法(’email=aaa@aaa.com&password=123456′);

POST /api_mobile/user/login HTTP/1.1
……
enc_data=加密数据字符串&login_type=1&appkey=123456&api_ver=1&timestamp=11111111&sign=654safag

而这个自创标准就可能存在数个问题：加密算法有问题导致轻易破解；加密算法有问题导致容易遭受中间人攻击解密；enc_data相同内容不变可被用于重放攻击；enc_data控制不良可能导致Hash Collisions Ddos……而以上的这些问题，怎么看，似乎难以轻易地归为场景问题？

PS：@GaRY 你的第一点意见似乎就是“开放设计原则”（开放设计原则规定机制的安全性不应依赖于机制设计与实现的保密性）？第二个意见确实提醒了我应该关注思考的成本问题，比如Oauth 1.0到2.0。

@horseluke 这个场景未必算什么自创标准吧。你这只是传输的数据内容自己做了加密。和传输本身标准或对应的api接口无关，也没有修改到什么RESTFUL之类的原则。如果硬要说加密算法是自创的问题，对应的加密算法是否找个开源或者强大的算法，我倒是觉得无所谓，不用这么较真，投入产出也得成比例不是。还是继续考虑实现成本和受攻击可能性的对比。

@GaRY 可能我这个例子没有讲明白，我在发布的博文中详细阐述了：http://www.iirr.info/blog/?p=899
你讲得对，成本和攻击可能等也许是自己想太多了，这个度还在掌握中。

HTTPS

1.不重复造轮子.节省大量工作.并有经验可寻
2.站在巨人的肩膀是,很多东西不用自己考虑.创建之初就为你考虑好了.