我知道有些大玩家已经接受了它,并且实际上已经以APP兼容的方式公开了他们的一些服务。但是,我还没有在这个领域找到很多其他(较小的)球员。您是否知道使用APP作为其公共API协议的任何Web应用程序/服务?什么是你的自己对AtomPub的看法?你有使用它的实际经验吗?它的局限和缺点是什么?你更喜欢AtomPub作为你的REST风格还是你有其他喜欢的?为什么?
我知道,这些是很多问题,而不仅仅是一个问题。我对此感兴趣的事情很简单 - APP标准是如何进入市场的,特别是它在网络开发者中的应用程度如何?
答案 0 :(得分:3)
我工作的公司正在开发大量RESTful服务。 但是,它们都没有暴露公共API。(从某种意义上说,所有服务都由我们自己的客户端内部消费)。我们采用REST架构风格的原因是我们希望我们的服务易于使用,更重要的是可以很好地扩展。
根据我自己的实践经验,我得出的结论是HTTP + ATOM联合格式是一个好主意,只要你想保持灵活性(根据不同的内容模型,附加和扩展与有效载荷相关的元数据,统一解析等)。 ATOM确保每个人以统一的方式解释有效载荷,而没有任何模棱两可的余地。
然而,如果一个人没有任何这样复杂的要求或者没有预见到这样的要求,那么ATOM格式可能会有点开销。 (例如,作者,标题等元素在博客/ RSS世界中更有意义,在您的特定问题域中可能没有意义。)
此外,如果目标是在一端序列化数据结构并在另一端重建它,那么大多数Web框架(如WCF)都具有更具吸引力的自定义格式。
所以在我看来,如果你需要在数据表示方面具有灵活性,并且如果游戏领域对于不同类型的客户来说是巨大的,那么ATOM Pub是好的。
但是,如果您对潜在客户和服务器/客户端使用模式有很好的了解,那么自定义格式可能是一个好主意。
如果客户端是基于浏览器的,那么像JSON这样的格式非常有吸引力。
希望这能回答你的问题。
答案 1 :(得分:2)
到目前为止我自己的研究:
答案 2 :(得分:2)
还有mod_atom - 一个Apache模块,用于存储文件系统中的条目。
答案 3 :(得分:1)
上次我检查(2007年左右)Atompub实施起来相当复杂。虽然您可以在午休期间将可以发出有效Atom供稿的东西组合在一起,但实施AtomPub是一项相当大的工作。
由于更好的库和工具,这可能已经发生了变化,但由于它很酷,它可能太复杂而不能被较小的一方实施。
缺乏杀手级的AtomPub客户端应用程序对服务器运营商施加很小或没有压力来提供AtomPub接口。