RPC Thrift或GRPC等RPC框架或任何其他RPC框架是RESTful吗？

Question

为了澄清 RESTful 的含义，它应该满足以下约束，取自here：

• 统一界面

• 无状态

• 可缓存

• 客户端 - 服务器

• 分层系统

• 按需代码

从我的研究中，我认为它们不是RESTful，主要是因为：

1. 他们不使用HTTP动词。

2. 他们不使用HTTP响应代码。

3. 它们不遵循基于 HATEOAS 的REST连接性原则。

有关上述结论的数据的详细信息，请参阅this资源。

像these这样的资源似乎表明这些框架可以作为RESTful使用/实现。

请参阅您基于答案的资源。这个问题旨在清楚地强调引用官方资源对该主题的误解。

Answer 1

  

Apache Thrift或GRPC等RPC框架或任何其他RPC框架是RESTful吗？

孤立地采取行动：否。

关于REST的最终参考是documentation。 Roy Fielding描述了在处理Web标准（Architectural Styles and the Design of Network-based Software Architectures，RFC 1945，RFC 2068，后来RFC 2616）时开发的架构限制。

  

REST适用于跨多个组织（RFC 7230）

的基于网络的长期应用程序

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

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

  

这些资源似乎表明这些框架可以作为RESTful使用/实现。

将REST理解为HTTP + JSON的人将得出与Web架构和Fielding论文不一致的结论。

简而言之 - HTML在使Web架构风格成功的过程中做了很多重要的工作。相反，JSON不包括“链接”或“形式”的语义，可用于与客户端进行哪些转换是可能的。您需要在JSON之上使用一些其他语义，以允许服务器与客户端通信哪些应用程序可以转换;要么是Fielding, 2008，要么是超媒体感知的JSON方言。

据我所知，可以使用Thrift创建满足REST架构约束的应用程序。但我的猜测是，它不会是一个特别令人满意的体验：Thrift的开发是因为Facebook需要一个具有Web架构所不满足的属性的系统。

  

REST非常适合网络使用。但是，由REST，HTTP和JSON组成的堆栈对于内部数据传输所需的高性能来说并不是最佳选择。实际上，这些协议和格式的序列化和反序列化可能会对整体速度产生不利影响。 - Web Linking

URI，HTTP，HTML很容易改变用途，但这种灵活性需要成本。在灵活性不能提供价值的环境中（例如，因为您是控制客户端和服务器部署的单一组织），更有效的格式和协议会变得更有趣。

它类似于我们在HTML和JSON之间做出的权衡 - JSON不是一个有用的超媒体表示;但是，通过我们的超媒体表示加载的按需代码消费完全令人满意。

马匹课程。

Answer 2

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

此外，应该避免尝试通过发明一些＆＃34; RPC over REST＆＃34;来解决为RPC而烦恼的问题。解决方案 - 程序员SE充满了这些问题。

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

所以我说这个问题是（某种）类别错误。