诸如Apache Thrift、GRPC或任何其他RPC框架都是RESTful的吗？

为了澄清我所说的RESTful的意思，它应该满足以下约束条件，这些约束条件取自：

• 均匀界面

• 无国籍

• 可缓存

• 客户端服务器

• 分层系统

• 按需编码

从我的研究中，我认为他们并不安静，主要是因为：

他们不使用HTTP动词

它们不使用HTTP响应代码

它们不遵循基于HATEOAS的REST连通性原则

有关上述结论所依据数据的更多信息，请参阅参考资料

一些参考资料似乎建议这些框架可以作为RESTful使用/实现

请参考您的答案所依据的资源。这个问题旨在澄清关于这个主题的误解，并强烈引用官方资源

诸如Apache Thrift、GRPC或任何其他RPC框架都是RESTful的吗

单独拍摄：没有

关于REST的最终参考是。Roy Fielding描述了在处理web标准（、之后）时开发的体系结构约束

REST适用于跨多个组织的基于网络的长期应用程序（）

“万维网”将是使用REST架构风格构建的应用程序的一个示例

HTTP方法和状态代码本身不是REST约束。在REST体系结构中，客户机和服务器通过交换消息共享语义，但这些消息不一定是HTTP消息。您可以用另一个符合体系结构风格的协议替换HTTP，并且仍然具有REST体系结构

一些类似的参考资料似乎表明这些框架可以作为RESTful使用/实现

理解REST意味着HTTP+JSON的人将会得出与web架构和Fielding的论文不一致的结论

简言之，HTML在使web架构风格成功方面起了很大的作用。相反，JSON不包含可用于与客户机进行通信的“链接”或“表单”的语义，而客户机可以进行哪些转换。您需要在JSON之上添加一些其他语义，以允许服务器与客户端通信哪些应用程序转换是可能的；JSON的一种或一种支持超媒体的方言

据我们所知，您可以使用Thrift创建满足REST架构约束的应用程序。但我的猜测是，这不会是一个特别令人满意的体验：节俭之所以被开发，是因为Facebook需要一个具有网络架构无法满足的特性的系统

REST对web非常有用。然而，由REST、HTTP和JSON组成的堆栈对于内部数据传输所需的高性能来说并不是最优的。事实上，这些协议和格式的序列化和反序列化可能会影响总体速度

URI、HTTP和HTML很容易重新调整用途，但这种灵活性伴随着成本。在这种灵活性无法提供价值的环境中（例如，因为您是一个控制客户端和服务器部署的单一组织），更高效的格式和协议会变得更有趣

这类似于我们在HTML和JSON之间进行的权衡——JSON不是一种有用的超媒体表示形式；但是，对于我们的超媒体表示加载的按需代码来说，它是完全令人满意的

---

马术课程。

根据定义，REST不是RPC，因为REST最显著的区别在于它是面向资源的，而RPC（通常）不是

此外，人们应该避免试图通过发明一些“RPC优于REST”的解决方案来解决迫切需要RPC的问题——程序员SE充满了此类问题

事实上，这种方法是颠倒的：一个人可以通过RPC实现一个基于REST的系统，但是为什么要使用REST的整个想法是在一个完全不同的抽象平面上的

所以我认为这个问题（有点）是一个分类错误