领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
REST API还有新麻烦？
作者 Mark Little 译者 王恒涛 发布于 2011年7月1日
最近George Reese正在把他和Adrian Cole共有的一些在云端使用各种SOAP和REST API的经验写出来，对此我们早先也做了报道。现在George的原作在twitter和各类博客中激起了大量的辩论。例如，William Vambenepe同意他大部分的言论，但有一小部分持不同意见，比如说对JSON和XML的支持：
我不赞成：有两个版本的协议就说明有一个是多余的（这个链接后的帖子并不是特别在讨论JSON/XML的对立性，但它的逻辑可以适用，就像Tim Bray在评论中所指出的一样）。
而William也不同意George声称REST比SOAP要好：
未必对所有集成项目来说都是正确的，但在云API的背景下，我同意这一点。只要它是“实用的REST”，而没有为了取悦REST警察而做些很傻的扭曲。
有意思的是，有一个看法引起了William的注意．．．
提供优秀的API文档减少了我对你帮助的需求：这是不言而喻的（要是想找找笑点，看看George博客文章里这位评论者，他写道“如果你给一个API写文档，你的API马上就跟REST没关系了”，我情愿相信这只是玩笑，不过看起来好像写得很认真）。
......这是来自于Jan Algermissen，他很严肃地回答了William的评论：
关于“提供优秀的API文档减少了我对你帮助的需求”。如果你给一个API写文档，你的API马上就跟REST没关系了。在RESTful系统中真正的约定是媒体类型，而不是API文档。我建议你把那部分放到“缺点”！请看：http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
然而，Stu Charlton引起了可能是最热烈的讨论，并在他的关于API的麻烦的文章中总结成了5点。
- REST API是一个好心办坏事的例子。REST的目的就是消除特定的API，而不是滋生它们。
- 如果谁告诉你不应该为REST API写文档，他们实际是在说你不该写API，而不是说你不该写文档。
- 话说回来，说你不该写API的REST的拥趸也有点傻，因为他们也没有提出什么好的选择。定制的媒体类型算不上一个。
- 这样说来，以我的观点，在我们有一两个可利用的普遍媒体类型之前，对80%的REST API来说，我们只是自寻烦恼。
- 我已经差不多放弃拥护REST了，因为现在来看不太可能。人们只是想发布一些只能用6个月的API，而不是构建可以进化10年以上的系统。
特别地，关于Jan早前的评论，Stu在下面表示了支持：
Jan Algermissen的关于如果你做API文档你就不是在做REST的看法实际上基本说到了点子上，但却被人冷嘲热讽。我完全理解，如果你只想在眼下发布一个API，如果短期行为是有意为之，或者以架构式风格玩弄新潮名词，这个评论听起来有多傻。但是如果我们真的想要利用这个风格的优点，我们就会着手解决核心的问题，为这些用例设计一两个通用媒体类型。
就像在REST社区中最常见那样，Stu的文章也引来了来自正反双方许多有趣的评论。进而，可以说这个争论是与我们前面一篇文章密切相关，这篇文章是关于REST是否可以被认为是在企业内成功的，而且同样也可能与Jean-Jacques相信我们现在正处在一个后REST/SOAP世界的原因密切相关。
REST 所制造的问题（……）在于，现在随便一个API设计者都自认为称得上是分布式计算的大师，像个艺术家般决定把版本和凭证之类的东西放在什么样的地方，凭自己喜好把操作和查询编码到一堆报文头、符号、查询参数、报文体等等之中。要是你问我的话，我得说REST制造了软件工业中前所未有的暴政。
Stu最后以他认为应用REST导致的一些规则变化作为总结：
- 你不能假设你的服务的最终用户是一个程序员（或浏览器）。Stu的看法是，如果你的目标是让程序员学习你的API，那就没有必要使用REST。
- 你不能假设只有一个站点会实现你的接口。“WEB的整体精神是分享信息——发布一个API造成作为发布者的你在全权控制的假设。其实是消费者——客户端代理本身控制着什么样的信息如何被消费和操作。”
- “需要文档化的接口语义是你用来描述你的数据和链接的媒体类型。你的URL的结构绝不应该成为这个语义的一部分。”
- “但是在定制的媒体类型里这么做说明你是唯一一个实现你自己的接口的人。当然每个媒体类型总要有个开始，但是这确实没什么帮助，除非你理解其他人可能会实现你的接口而不只是与之会话。
他提出的最后一点规则的改变值得单独提出来因为它多年来都是很多争论的主题:
我们所能希望的最好的情形是有人或组织能承担这个责任提出一两个通用媒体类型以及指南，来帮助描述和文档化一个数据WEB的接口给程序员使用。如果你愿意可以称之为描述语言。一些REST的拥趸不喜欢描述语言这个想法，而我认为这实际是80/20的比例，如果开发者真的打算用它原本的用法去使用这个架构。
那么你是怎么想的？我们是光缺少良好定义的设计好的REST API的规则，还是像JJ暗示的那样这是一个失败的运动？
查看英文原文： Yet More Trouble with REST APIs?
译者 王恒涛 从事软件行业开发近10年，多有涉猎，并无精通，晓英、日语。愿为知识的分享与流通尽点薄力。
REST无罪
发表人
Yang Bob
发表于
1 条回复
关注此讨论 回复