成为RESTful是否很重要？

Question

我正在开发一个基于Web的应用程序，使用JSON over HTTP API在服务器和客户端之间进行通信。其目标是可以开发具有不同目的（在线Web客户端、离线桌面客户端或第三方创建）的多个客户端，通过此Web服务共享相同的在线数据。

目前，客户端和服务器之间的通信仅通过POST发送，而这种方式已经很好地运作。我阅读了大量关于REST和如何使用PUT、GET、POST和DELETE实现RESTful HTTP的信息。我可以将我的API分成这些不同的类别，但这意味着需要更多的代码和对API进行一些更改。

我的问题是：HTTP API要成为RESTful非常重要吗？是推荐、可选还是必须的？

提前感谢您的回答。

- trydyingtolive

Answer 1

作为一个死忠RESTafarian，我建议充分利用HTTP（所讨论的REST协议）。为什么？好吧，我将向你展示昨天我与一位非常聪明的好朋友通过电子邮件交流的两个片段（他曾是IT教授，现在依然讲课，在任何地方都能成功）;

昨天，我为我的mappodrhom应用程序实现了一个重要的里程碑：我现在可以将长时间运行的后台计算投入到工作池中。当它们完成时，工作者直接将其结果POST回REST资源。这将触发更多的后台处理，所有这些都由依赖图控制。

有趣的是，这种RESTful的后台处理实际上与我的特定应用程序无关。但我现在太累了，完全无法理解其后果 :-)

所讨论的后果是巨大的（它是一个REST框架，具有许多小堆栈、事件和服务以及应用程序，所有这些都有自己可发现的URI，并具有相同的统一接口），就可扩展性和可伸缩性而言，它的简单性是无与伦比的。如果您的应用程序是一个微不足道的东西，永远不会旅行或遇到热辣的妹子，那么也许您不需要它。但是，我曾经说过同样的话，突然发现自己坐上了去巴黎的火车，和一个为俄罗斯人做秘密间谍的可爱女孩在一起，好吧，事情就这样发生了...

这是我的回复，附带一些我自己的经验;

我认为这听起来（原谅我的法语）特别棒！我在自己的REST项目中也遇到了类似的事情，因为中间层非常薄且透明，所以我可以按照自己的需求扩展它们，而不必过多担心基础架构。这是一种自由，一种酷炫的东西，让我的大脑即将爆炸，也让我好奇为什么没有更多人这样做呢？

简而言之，只做REST的一半就像根本没做一样。你只是把你的东西移到了另一个管道上，错过了进入状态机、语义和实现解耦的简化API，在核心上使用建立网络的原则（因此我会说你背后有相当可靠的思想），统一接口，并将URI作为你的建模的一部分。

我知道说你可以挑选和选择很流行，说这只是选项。但事实并非如此。只有完全使用REST才有意义，但是要说服你真正推动自己的思维，做一些聪明的事情，我只能敢你去除FUD（它全部都是关于RPC，只需要GET和POST，你不需要所有这些，等同于JSON，SOAP和其他的东西等），并更加聪明地制作应用程序。 是的，我敢你们所有人！

- AlexanderJohannesen

---

有趣。是什么阻止了你的朋友使用SOAP Web服务编写应用程序？ - John Saunders

智商？ :) 说真的，要在SOAP之外做事情，你需要理解WS-*堆栈才能有意义，但是WS-*堆栈重新发明了已经以更加优雅的方式解决的东西，特别是在可扩展性、状态机和易用性方面。需要寻址吗？使用WS-*，您需要遵循寻址标准，而使用REST，您只需放置URL并重定向到所需位置，并根据响应代码更改缓存或设置。使用REST已经做得更好了。在某些方面，这是对传统的自由。 - AlexanderJohannesen

所以，不是不能做到，也不是REST提供了SOAP堆栈没有的某些功能，而是你不喜欢SOAP堆栈？ - John Saunders

John，这两者实际上是无法比较的。毫无疑问，你可以通过SOAP做几乎所有的事情，但你必须考虑它带来的权衡，其中包括需要理解1200页的标准材料、技术堆栈实现（这就是为什么它是企业服务总线的载体；它变得非常庞大和复杂）。现在，REST并不像SOAP那样强大，它只是一种机制，用于处理你想要做的事情，但它将你的注意力从RPC转移到了通过URI进行分布式资源管理的东西上，这正是构建Web的东西，也是一个好东西（商标）。 :) - AlexanderJohannesen

重要的是，REST 依赖于通过超文本管理资源 - URI 本身并不重要。与 RPC 相比，REST 服务更加灵活，因为耦合度更低 - 客户端只知道一个 URI。 - aehlke

Answer 2

除非您打算利用超媒体，否则我不建议尝试符合REST约束。 超媒体是使系统大于其部分之和的关键因素。

您可以自由选择要在架构中遵守哪些REST约束，但请注意，为了能够称之为RESTful的最终结果，唯一可选的约束是“代码下载”。

- Darrel Miller

Answer 3

这是一种选项，可用于将Web应用程序公开为具有明确定义API的Web服务。其他选项包括：

1. 无API - 应用程序没有真正的方法用作其他分布式系统中的组件
2. SOAP - 用于定义API远程调用的XML格式
3. JSON - 一种紧凑的信息交换格式，可用于构建自定义API格式（或用于构建REST系统，如果您想要）
4. 许多其他形式的远程过程调用和信息交换媒介。

REST背后有一个很好的理念，但这并不意味着您必须为应用程序提供REST API。如果收益不值得额外的努力，请不要费心。

- workmad3

---

REST与响应格式无关，除了需要响应为超文本（基本上需要具有指向其他资源的URI或类似内容）。 - Hank Gay

JSON只是一种数据格式，不是REST或HTTP的“替代品”。它可以与它们一起使用，也可以单独使用。（我认为Hank可能在表达同样的观点。） - system PAUSE

此外，SOAP 不仅定义数据传输格式；它还要求服务是自描述的，这允许创建强类型的代理客户端来访问服务。然而，我不知道 JSON 定义除了格式之外的任何内容，所以如果您有参考，请提供 URL。 - John Saunders

Answer 4

这是一个建议。我很高兴你没有深入讨论需要多RESTful，因为有一种叫做Hi-Rest和Lo-REST的东西。你可以通过谷歌获取更多信息。我认识的一些行业老手并不太在意这个，但我发现尽可能接近HTML和HTTP将有助于你长期发展，并简化许多事情。

- Srikar Doddi

---

引用 REST 的“发明者”Roy T. Fielding的话：“[T]没有所谓的“Common REST”（同样地，“Low REST”和“High REST”的替代声明也是如此）。只有REST。” - aehlke

为什么我们总是要引用Roy Fielding的话？ - Srikar Doddi

进化生物学家为什么总是引用查尔斯·达尔文的话？ - Day

Answer 5

我认为这是一个不错的选择，但并非必须。根据我的经验，添加这种架构会增加项目的范围和复杂性，但确实会给整个项目增添一定的优雅感。如果你在项目中有足够的时间和预算，那就去做吧，否则就不要担心它。

- James

Answer 6

在考虑服务API时，需要考虑的一件事情是它们是否易于最终用户使用。REST正在获得非常强大的工具支持。

迄今为止，最大的开发人员群体是.NET开发人员群体，而使用ADO.NET for services（Astoria）消耗REST并使用Linq非常简单和优雅。

- Tim Jarvis

---

使用提供的客户端库，消费基于http并遵循一些REST约束的ADO.Net数据服务非常简单和优雅。但是，声称使用Linq消费REST非常简单和优雅是一个巨大的飞跃。 - Darrel Miller

“声明”是使用Astoria消费REST非常简单和优雅。也许你应该再次阅读我的回答。我从未声称在服务外部使用linq消费ADO.NET的任何东西。 - Tim Jarvis