为什么 ODATA 没有被开发人员广泛用于 RESTful 开发？
Why is ODATA not widely adopted by the developers for RESTful development?
将 odata 用于其 REST 实现的开发人员社区似乎是我经常遇到的所有 REST 实现中最少的。
有什么原因吗？
OData 是公开数据集的绝佳标准，具有良好的工具支持（Excel、Tableau、PowerBI...）。
就我而言，它为我节省了大量时间和精力，projecting/sorting/filtering...开箱即用，无需编写任何代码（尤其是使用 .net）。这是我在 table 类结构上选择 RESTful API 的选项。
前几天，我与一家大型外包公司的承包商进行了一次有趣的谈话。他为许多客户构建了 restful API，当我问他是否有时使用 OData 时，他回答说“我们不使用 OData，我们更喜欢 Json”（叹息...）。
所以我想您的问题的可能答案之一是无知，许多人根本不知道或不了解 OData...
几乎没有合同。服务消费者不知道如何使用该服务（例如，什么是有效的命令参数、编码期望等）。
界面在接受的内容方面过于宽松。
合同未向消费者提供有关如何使用该服务的足够信息。如果消费者必须阅读服务签名以外的内容才能了解如何使用服务，则应审查服务的保理。
消费者在使用 Web 服务之前应该熟悉数据库和 table 结构。这导致服务提供者和消费者之间的紧密耦合。
由于对延迟绑定的依赖以及同一服务内边界之间的 encoding/decoding，性能将受到影响。
将 odata 用于其 REST 实现的开发人员社区似乎是我经常遇到的所有 REST 实现中最少的。 有什么原因吗？
OData 是公开数据集的绝佳标准，具有良好的工具支持（Excel、Tableau、PowerBI...）。
就我而言，它为我节省了大量时间和精力，projecting/sorting/filtering...开箱即用，无需编写任何代码（尤其是使用 .net）。这是我在 table 类结构上选择 RESTful API 的选项。
前几天，我与一家大型外包公司的承包商进行了一次有趣的谈话。他为许多客户构建了 restful API，当我问他是否有时使用 OData 时，他回答说“我们不使用 OData，我们更喜欢 Json”（叹息...）。
所以我想您的问题的可能答案之一是无知，许多人根本不知道或不了解 OData...
几乎没有合同。服务消费者不知道如何使用该服务（例如，什么是有效的命令参数、编码期望等）。
界面在接受的内容方面过于宽松。
合同未向消费者提供有关如何使用该服务的足够信息。如果消费者必须阅读服务签名以外的内容才能了解如何使用服务，则应审查服务的保理。
消费者在使用 Web 服务之前应该熟悉数据库和 table 结构。这导致服务提供者和消费者之间的紧密耦合。
由于对延迟绑定的依赖以及同一服务内边界之间的 encoding/decoding，性能将受到影响。