我们正在考虑将Odata协议用作我们服务的REST标准。 根据我的研究，我没有看到2007年由MS发起的Odata的广泛采用，但现在它已于2014年开放。我甚至看到一篇文章指出像Netflix和Ebay这样的大玩家已经离开它{{3} }。
我发现以下基于互联网搜索的限制以及之前有关odata的问题（如果我提到的限制不正确，我会事先道歉）：
你们能否与Odata分享你的经验，这将有助于我们做出正确的决定？
答案 0 :(得分：2)
为具有C＃后端和Excel作为客户端的报告系统实施了基于OData的解决方案，我不得不说我对Iv所看到的内容非常满意。在基于.Net的项目中 - OData易于开发，可靠且快速开发。查询功能非常令人印象深刻，任何符合XML的客户端应用程序或组件都可以轻松处理数据（以XML格式返回）。
话虽如此 - 在接近大型项目时 - 您可能会考虑与我的不同（您在上面写的大部分内容）。
OData的传播确实不是很广泛。未来的支持是一个重要的考虑因素，OData兼容技术的提供商如果认为OData没有被使用，可能会放弃对OData的支持。仍然 - 我相信它不会很快消失。开源项目也是如此 - 它反映在市场上OData的采用水平。
安全性是任何数据消费应用/服务的重要考虑因素。在这里 - 我不会转发任何黑盒解决方案。我将安全方面与业务逻辑分开，由处理器在单独的层中处理（在业务逻辑组件甚至开始处理请求之前）。有些人可能会提供其他方法，以更好地满足他们的需求。有很多关于保护OData服务的文章。你应该做更多的研究，因为这是一个很大的话题。
缓存是一个与数据消费不同的主题，所以说OData缺乏对缓存的支持就像说'＃34;我的车无法制作咖啡＆＃34; :)
缓存（主要）受用户数据消费模式的影响，因此您应该检查应该缓存的内容以及不应该缓存的内容。您可以使用大量缓存组件。
您所撰写的限制应与您现在参与的项目相关联。很难对天气进行辩论，这会促进不良做法，但是当你使用像MS的OData这样的黑盒子组件时，你会付出代价。
总结一下 - 当我开发小规模应用程序时，我OData缩短了开发时间，但是当涉及到大规模的企业级应用程序时， - 它不会是我的第一选择，而且我不会这样做。我不确定我是否会推荐给其他人，除非OData对特定项目的好处是很大的好处。
祝你好运！