我正在开发一个基于 Web 的应用程序，该应用程序使用基于 HTTP 的 JSON 的 API 在服务器和客户端之间进行通信。目标是可以使用通过此 Web 服务共享的相同在线数据开发具有不同目标的多个客户端（在线 Web 客户端、离线桌面客户端或第三方创建）。
现在，客户端和服务器之间的通信仅通过运行良好的系统通过 POST 发送。我阅读了大量关于 REST 以及使用 PUT、GET、POST 和 DELETE 使用 HTTP 实现 RESTful 的信息。我可以将我的 API 分成这些不同的类别，但这意味着更多的代码和对 API 的一些更改。
我的问题是：对于基于 HTTP 的 API 而言，RESTful 有多重要？它是推荐、选择还是近乎必需？
提前致谢。
作为一个顽固的 RESTafarian，我想说的是充分利用 HTTP（有问题的 REST 协议）。为什么？好吧，我将向您展示我昨天与我的一位非常聪明的好朋友（曾经是 IT 教授，仍然在讲课，无论走到哪里都踢屁股）的电子邮件交流中的两个片段；
昨天我通过了我的 mappodrhom 应用程序的一个重要里程碑
：我现在可以将长时间运行的后台计算启动
到工作池中。当他们完成时，工作人员将他们的结果直接发布到 REST 资源中。这会触发更多的后台处理，所有这些都由依赖图控制。有趣的是，这种 RESTful 后台
实际上独立于我的特定应用程序。但我
目前太累了，无法完全掌握后果:-)
有问题的后果是巨大的（它是一个 REST 框架，有很多小堆栈、事件、服务和应用程序，都有自己的可发现 URI，都具有相同的统一接口），并且就可扩展性和可伸缩性而言，它在它的简单性。如果您的应用程序是一个永远不会去旅行或遇到辣妹的小东西，是的，也许您不需要它。但是后来，我也说了同样的话，突然发现自己在去巴黎的火车上和一个可爱的女孩，她是俄罗斯人的秘密间谍，嗯，一件事导致了另一件事……
这是我的回答，并附有我自己的一些经验；
我觉得这听起来（请原谅我的法语）太棒了！我在使用自己的 REST 东西时遇到了类似的事情，因为中间层非常薄且透明，我可以按照我需要的方式扩展东西，而不必过多担心基础设施。这是一种如此自由，如此酷炫的事情，我的大脑快要爆炸了，还有一种令人担忧的好奇心，为什么更多人不这样做？
简而言之，只做 REST的一半就像根本不做。你只是将你的东西转移到一个不同的管道上，错过了一个简化的 API 到一个状态机、语义和实现解耦的核心，使用构建网络的原则（因此我会说你'你背后有相当成熟的想法），统一的界面，以及将 URI 作为建模的一部分。
我知道人们常说你可以挑选，一切都只是选择。它不是。REST 只有在充分使用它时才有意义，但要说服你真正扩展你的大脑并做一些聪明的事情，我只能敢于让你切开 FUD（这完全是关于 RPC，只有 GET 和 POST 是必要的，你不需要它全部，相当于 JSON、SOAP 和其他类似的等等），并且更聪明地了解你如何制作应用程序。是的，我敢你们！
除非您打算利用超媒体，否则我不会费心尝试遵守 REST 约束。超媒体是拼图的一部分，它使系统大于其部分的总和。
您可以自由选择要在架构中尊重哪些 REST 约束，只需注意，为了能够调用最终结果 RESTful，唯一可选的约束是“代码下载”。
它是一种将 Web 应用程序公开为具有明确定义的 API 的 Web 服务的选项之一。其他选项包括：
REST 背后有一个很好的理想，但这并不意味着您必须为您的应用程序提供 REST API。如果收益不值得付出额外的努力，请不要打扰。
这是一个建议。我很高兴你没有进入你需要进入的 RESTful，因为有一种叫做 Hi-Rest 和 Lo-REST 的东西。您可以通过谷歌搜索获得更多信息。我认识的一些行业资深人士不太关心这一点，但我确实发现，从长远来看，与 html 和 http 保持接近会帮助您并简化许多事情。
我认为拥有它是一件好事，但不是必须的。根据我的经验，添加这种架构会增加项目的范围和复杂性，但它确实为整体增添了一定程度的优雅。我想说，如果你有时间和预算来做这个项目，那就去吧，如果没有，不要担心。
服务 API 需要考虑的许多事情之一是最终用户可以轻松地使用它们。REST 正在获得非常强大的工具存在。
到目前为止，最大的开发组是 .NET 开发组，使用 ADO.NET for services (Astoria) 使用 Linq 使用 REST 非常简单且非常优雅。