被雷了，关于国内某著名软件集成商的“非著名 API” ，提出几条，大概可作为部署 Web Service API 通用行为准则：

1. 团队： 作为软件研发，实施团队，不要留小人，更不要让一群小人存在； 话说回来，团队头儿们也是这样? 无话再讲...

2. 架构师： Web Service API 应该满足“极简、抽象、前瞻”，作为 API 的设计者，需要“长期的、极为丰富的”工程经验，如果找个只会抄写论文的专家，只能毫无导向、反反复复的从零开始； 更为严重的是，其幽默的表演，会影响团队，相关合作商，使大家一并“崩溃”

3. API 协议轻量化，参数字段名短小，通讯响应快速

4. API 应用服务器应该隐藏任何涉及系统、平台、代码级别的异常。 不能像“非著名 API” 那样，部署一年，还轻易的抛出代码级异常信息，搞笑

5. API 任何请求都应该返回明确状态，如果存在异常，就应该抛出友好的消息提示。 “非著名 API” 要么打死都不说，要么就一下子抛出源代码，NND，见过垃圾的，没有见过这么垃圾的 ...

6. API 应该具备完善的认证、校验机制，裸奔就是找死，意味着设计者智商有问题

7. API 任何相邻版本升级都应该向下扩展，或并行存在，为新旧版本的升级准备兼容期。

8. API 应该提供 “工整、准确” 的文档，“非著名 API” 的文档，发布一年了，版面像狗爬，内容像草稿。

9. API 应该同时提供生产和Demo两种API，提供主流开发语言的测试用例，快速的技术支持，积极的态度，避免出现 “昨天还是好的啊，我没动过，我不知道” ，“我下班了， 88” 之类答复，留你何用？
--EOF--