为什么我们需要RESTful Web服务？
我将学习REST风格的Web服务（最好是说我必须这样做，因为它是CS硕士学位课程的一部分）。
我已经阅读了维基百科中的一些信息，并且在Sun Developer Network上也阅读了一篇关于REST的文章，我发现这不是一件容易的技术，有构buildRESTful应用程序的特殊框架，而且通常与SOAP Web服务和程序员应该明白什么时候使用SOAP，什么时候REST可以是很好的方法。
我记得几年前，SOAP是非常stream行的（时髦？），每一个好的简历都必须包含“SOAP”。 但在实践中，它很less被使用，并且达到了非常简单的目的。
在我看来，REST是另一个“时尚的最后一个字”（或者我可能完全错误，因为我从来没有见过REST的实践）。
你能给我举一些REST应该使用的例子，为什么我们不能在没有REST的情况下做同样的事情（或者为什么我们不花费更多的时间来做同样的事情而不使用REST）呢？
乌兹别克斯坦 ：不幸的是，我看不到任何具体的论点，可以在第一个评论中打动我的脑海。 让我觉得REST是真棒技术！
我想看到这样的答案：
我正在开发另一个复杂的HelloWorld应用程序，我们需要传输大量/微小的数据，并向我的同事提出了REST解决scheme：
– 哦，该死的！ 强尼，我们当然应该使用REST来实现这个应用程序！
– 是的，比利，我们可以使用REST，但是我们最好使用SOAP。 相信我，因为我知道开发HelloWorld应用程序的一些东西。
但是SOAP是上个世纪的老式技术，我们可以使用更好的技术。
– 比利，你准备好花3天时间来试用REST吗？ 我们可以在2小时内用SOAP来做到这一点。
– 是的，我相信我们会花更多的时间来实现相同的安全/性能/可伸缩性/其他任何与SOAP有关的事情。 我确信HelloWorld应用程序应该从现在开始只用REST开发。
如果在分布式应用程序中最小化客户端和服务器组件之间的耦合对您非常重要，则应该使用REST。
如果您的服务器将被许多您不能控制的不同客户端使用，则可能是这种情况。 如果您希望能够定期更新服务器，而无需更新客户端软件，也可能会出现这种情况。
我可以向你保证，实现这种低水平的耦合是不容易的 。 遵循REST的所有约束是成功的关键。 保持纯粹的无状态连接是困难的。 select正确的媒体types并将数据压缩成格式是棘手的。 创build自己的媒体types可能更难。
将丰富的服务器行为适配到统一的HTTP接口中可能会令人困惑，有时与相对简单的RPC方法相比，显得有些迂腐。
尽pipe存在困难，但是由于HTTP协议的一致使用，您拥有的服务是客户端开发人员应该能够轻松理解的。 由于超媒体 ，服务应该很容易被发现，并且客户端应该对服务器上的改变非常有弹性 。
超媒体的好处以及会话状态的避免使负载均衡变得简单， 服务分区变得可行 。 严格遵守HTTP规则使debugging器和caching代理等工具的可用性变得美妙。
更新
在我看来，REST是另一个“时尚的最后一个字”（或者我可能完全错误，因为我从来没有见过REST的实践）。
我认为REST已经变得时髦了，因为试图做SOAtypes项目的人发现使用SOAP堆栈他们没有意识到已经承诺的好处。 人们不断转向networking，以简单的整合方法为例。 不幸的是，我认为人们低估了创buildnetworking的计划和远见，并且过分简化了需要做什么来允许networking上发生的偶然重用。
你说你在实践中从来没有见过REST，但如果你使用networking浏览器，这可能不是真的。 Web浏览器是一个REST客户端。
- 当有人在网站上更改某些html时，为什么不需要更新浏览器？
- 为什么我可以将一整套新的页面添加到网站上，而“客户端”仍然可以在不更新的情况下访问这些新页面？
- 为什么我不需要向Web浏览器提供“service-description-language”来告诉它何时去http://example.orghttp://img.dovov.comcat ，返回types将是一个JPEG图像，当你去到http://example.org/description/cat的返回types是text / html吗？
- 为什么我可以使用networking浏览器访问浏览器发布时不存在的网站？ 客户如何知道这些网站？
这些听起来可能像是一个常见的问题，但如果你知道答案，那么你就可以开始看到REST是什么了。 看看StackOverflow获得更多的REST好处。 当我查看一个问题时，我可以为该页面添加书签或将该URL发送给一个朋友 ，他可以看到相同的信息。 他不必通过网站浏览find这个问题。
StackOverflow使用各种OpenId服务进行身份validation，gravatar.com为头像图片，谷歌分析和Quantserve的分析信息。 这种多公司整合是SOAP世界唯一梦寐以求的东西 。 最好的例子之一就是用于驱动StackOverflow用户界面的jQuery库从Google的Content Delivery Network中检索。 SO可以指导客户端（即您的Web浏览器）从第三方站点下载代码以提高性能，这一事实certificate了Web客户端与服务器之间的低耦合性。
这些是工作中的REST架构的示例。
现在一些网站/应用程序确实打破了REST的规则，然后浏览器无法正常工作。
- 臭名昭着的后退button问题是由使用服务器端会话状态引起的。
- 当你有服务器端的会话状态时，负载平衡会变成一种痛苦。
- Flash应用程序通常会阻止URL专门识别表示。
- 打破网页浏览器的另一个问题是不符合媒体types的标准。 我们总是听到有关IE6需要如何被杀死的消息。 问题在于标准没有得到适当的遵守，或者因为什么原因而被忽略。
- login会话的使用是许多安全漏洞的来源。
REST无处不在。 这是networking的一部分，使其工作得很好。 如果要构build像Web一样可伸缩的分布式应用程序，可以像Web一样灵活地进行更改，并且可以像Web一样促进重用，然后遵循与构buildWeb浏览器时相同的规则。
就我所知，REST是由Roy Fielding的论文Architectural Styles和基于networking的软件体系结构的devise开始的 ，如果你没有看过，那么值得一读。
在论文的顶部是一个引用：
几乎每个人都能感受到与大自然的和谐：倾听海浪，靠近岸边，寂静的湖水，草地，风吹的荒地。 有一天，当我们再次学习到永恒的方法的时候，我们对城镇也会有同样的感受，我们会感到和平一样，就像今天我们在海边漫步，或者在长长的草地上伸展一样草地。
– 克里斯托弗亚历山大，build设的永恒之路（1979）
那真的是把它总结在那里。 REST在很多方面更加优雅。
SOAP是HTTP上的一个协议，所以它绕开了很多HTTP约定来在SOAP中构build新的约定，并且在许多方面与HTTP是冗余的。 然而，HTTP对于通过HTTP进行撤销，search，写入和删除信息来说已经绰绰有余了，而这正是REST的一大特色。 因为REST是使用HTTP而不是在HTTP之上构build的，所以它也意味着要与之集成的软件（如Web浏览器）不需要理解SOAP，只需要HTTP就可以广泛的理解和整合 – 目前使用的协议。
从这里 ：
REST优点：
- 轻量级 – 不是很多额外的XML标记
- 人类可读的结果
- 易于构build – 无需工具包
还检查了这一点 ：
公平地说，REST并不是每个Web服务的最佳解决scheme。 需要安全的数据不应作为URI中的参数发送。 大量的数据，如详细采购订单中的数据，可能会很快变得繁琐或甚至超出URI范围。 在这些情况下，SOAP确实是一个可靠的解决scheme。 但是，首先尝试REST并且仅在必要时才使用SOAP很重要。 这有助于保持应用程序开发的简单和可访
我可以放心地说，我已经花了很多时间来理解这是一个初学者，但这是从头开始REST的最佳链接！ http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa
只要把你拉进来，
“想一下”传统的Web服务“是什么，它是一个暴露”方法“的接口，客户知道方法的名称，input和输出，因此可以调用它们。
现在想象一个不暴露“方法”的接口。 相反，它暴露“对象”。 所以当客户端看到这个接口时，它看到的只是一个或多个“对象”。 “一个对象”没有input和输出 – 因为“它什么都不做”。 这是一个名词，而不是一个动词。 这是“一件事”，而不是“一个行动”。
例如，想想一个传统的Web服务，如果您提供了一个城市，就可以提供当前的天气条件。 它可能有一个像GetWeatherInfo（）这样的Web方法，它将城市作为input并提供天气数据作为输出。 到目前为止，您很容易理解客户端将如何使用此Web服务。
现在想象一下，在上述的networking服务的地方，有一个新的城市作为对象。 所以，当你把它看作是一个客户，而不是GetWeatherInfo（），你会看到纽约，达拉斯，洛杉矶，伦敦等等。 而这些城市没有任何特定的应用方法 – 它们显然就像惰性气体 – 它们本身并没有反应。
你一定在想 – 呃，作为一个客户，怎么能帮助你达到达拉斯的天气呢？ 我们会在一会儿之后做到这一点。
如果你从networking服务中获得的只是一组“对象”，显然你需要一种“对它们采取行动”的方式。 对象本身没有方法供您调用，因此您需要一组可以应用于这些对象的操作。 换句话说，你需要“给动词加上名词”。 如果你看到一个物体，比如说一个“名词”的苹果，那么你可以把“吃”这个动词应用到它上面。 但并非所有动词都可以应用于所有名词。 就像，你可以开车，但不能开车。
因此，如果一个Web服务暴露“
大多数有关REST的“专业”答案似乎来自那些从未开发过SOAP Web服务或客户端的人员，他们使用的环境为该任务提供了适当的工具。 他们抱怨使用Visual Studio .NET和IBM的Rational Web Developer从未遇到的问题。 我想如果你必须用脚本语言或其他一些语言来开发networking服务或客户端，只需要很less或者没有工具支持，那么这些都是有效的投诉。
我也不得不承认，有些“专业”观点听起来像事实上可能是真实的 – 但我从来没有见过一个例子来说明它们的价值。 特别是，如果有人发表一条包含REST Web服务良好示例的链接的评论，我将不胜感激。 这应该是一个使用多层次的资源，可能在一个层次结构，并正确使用媒体types。 也许如果我看一个很好的例子，我会明白，在这种情况下，我会回到这里来承认它。
为了给已经给出的答案添加一个稍微平淡无奇的假设，我们使用REST服务的原因是，如果您知道可以向业务伙伴提交一个URL，并且知道他们将会收到一个很好的XML布局无论他们是在.Net xx，PHP，Python，Java，Ruby还是天知道的工作，它都会大大减less头痛的问题。
这也意味着在非技术方面我们的销售人员可以吹嘘我们的多functionAPI给人们，而不用担心看起来像完整的木偶。
除了技术上的好处之外，非技术人员很容易解释，展示和感觉自信是件好事。 SOAP虽然对于技术人员来说同样酷，但非技术人员却不那么平易近人，因此并不容易“出售”。
我倾向于注意到，非技术人员能够头部往往坚持下去。 所以我怀疑REST是否像SOAP一样容易受到时尚的影响。
但是所有关于不把任何东西放在应该被locking的REST服务中的东西是双重的，因为技术很容易被那些技术上不那么专注的人理解。
这里有一些想法：
- REST限制您的服务使用统一的界面。 您不必浪费时间做白日梦（或争论）关于您的服务可能工作的所有可能的方式 – 您能够正确地识别系统中的资源。 结果本身就是一个很大的工作，但幸运的是问题往往更加明确。
- 随着资源，协会和他们的交涉，实施你的服务真的很less，因为许多决定是为你做的。
- 你的系统看起来和其他RESTful系统非常相似。 为队友，合作伙伴和客户的学习曲线将会减less。
- 你会有一个共同的词汇来与其他开发人员讨论devise问题，甚至与那些技术不太专业的人（如客户）讨论。
- 正如Darrel所说，由于您使用的是超文本驱动的devise，您的服务将耦合的范围缩小到只有一种 – 媒体types。 这可以帮助您作为开发人员，因为您的系统更改包含在一个窄的联系人范围内。 这可以帮助您的客户更less的更改将破坏他们的代码。
- 几乎在实现REST时可能遇到的所有问题都可以通过公开新资源或重新考虑资源模型来解决。 这个重点是IMO，提高生产力。
底线，REST从您的团队的工作stream程中删除了许多最耗时，最有争议的devise和实施决策。 它将您的注意力从实施您的服务转移到devise 。 而且它没有把gobbledygook放到HTTP协议上。
REST是devisenetworking应用程序的架构风格。 这个想法是，不是使用诸如CORBA，RPC或SOAP之类的复杂机制来连接机器，而是使用简单的HTTP在机器之间进行调用。
在许多方面，基于HTTP的万维网本身可以被看作是基于REST的架构。 RESTful应用程序使用HTTP请求来发布数据（创build和/或更新），读取数据（例如，查询）以及删除数据。 因此，REST对所有四个CRUD（创build/读取/更新/删除）操作使用HTTP。
REST是RPC（远程过程调用）和Web服务（SOAP，WSDL等）机制的轻量级替代scheme。 稍后，我们将看到更简单的REST是多less。
尽pipe简单，RESTfunction齐全; 在Web服务中，基本上没有什么可以做到的，而RESTful体系结构无法做到这一点。 REST不是一个“标准”。 例如，REST永远不会有W3C推荐标准。 虽然有REST编程框架，但是使用REST非常简单，您可以经常使用Perl，Java或C＃等语言的标准库function“自行开发”。
