rest - 有谁知道遵循 HATEOAS 原则的 RESTful 客户端示例？

Question

关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。












想改进这个问题？将问题更新为 on-topic对于堆栈溢出。

去年关闭。




Improve this question




所以现在我明白了，我们都应该实现我们的 RESTful 服务，提供使客户能够遵循 HATEOAS 的表示。原则。虽然理论上这一切都说得通，但我一直在网上搜索，以找到一个严格遵循这个想法的客户端代码的一个很好的例子。

我读得越多，我就越觉得这是一场学术讨论，因为实际上没有人这样做!人们可以尽情地提示 WS-* 堆栈的许多缺陷，但至少很清楚如何编写客户端:您可以解析 WSDL 并生成代码。

现在我明白了，对于一个好的 RESTful 服务来说，这不应该是必需的:你应该只需要了解所涉及的关系和表示，你应该能够动态地对它们使用react。但即便如此，这个原则现在不应该被提炼和抽象到一些通用库中吗？输入有关您可能收到的表示和关系的信息并获得一些可以在您的应用程序中使用的更有用的更高级别的代码？

这些只是我的半生不熟的想法，但我只是担心如果我现在潜入并编写一个适当的 RESTful API，实际上没有人能够使用它!或者至少在后面使用它会很痛苦，因为人们将不得不编写胶水代码来解释我提供的关系和表示。

任何人都可以从客户的角度对此有所了解吗？有人可以展示一个正确动态/响应式(Reactive) RESTful 客户端代码的示例，以便我了解我实际为之写作的受众吗？ (最好还是一个提供一些抽象的客户端 API 的例子)否则它都是非常理论的......

[编辑:注意，我发现了一个类似的问题 here ，我认为没有得到真正的回答，作者被维基百科 stub 骗了!]

Answer 1

我们目前的项目已经完成了一半。我们返回的表示是从域对象生成的，客户端可以使用 XML、JSON 或 XHTML 请求它们。如果它是像 Firefox 这样的 XHTML 客户端，那么人们会看到一组来自众所周知的根资源的出站链接，并且可以浏览所有其他资源。到目前为止，纯粹的 HATEOAS，对于开发人员来说是一个很棒的工具。

但是当客户端是程序而不是使用浏览器的人时，我们关心的是性能。对于我们的 XML 和 JSON 表示，我们目前已经抑制了相关链接的生成，因为它们使表示大小增加了三倍，从而大大影响了序列化/反序列化、内存使用和带宽。我们的另一个效率问题是，使用纯 HATEOAS，客户端程序在从众所周知的链接向下浏览到所需信息时，将发出数倍于 HTTP 请求的请求。因此，从效率的角度来看，如果客户了解其中编码的链接，这似乎是最好的。

但是这样做意味着客户端必须进行大量的字符串连接来形成 URI，
这很容易出错，并且很难重新排列资源 namespace 。因此，我们使用模板系统，其中客户端代码选择一个模板并要求它从参数对象扩展自身。这是一种填表方式。

我真的很想看看其他人在这方面的经历。除了性能方面，HATEOAS 似乎是一个好主意。

编辑:我们的模板是我们在 Restlet 之上编写的 Java 客户端库的一部分。框架。客户端库处理 HTTP 请求/响应、HTTP header 、反序列化/序列化、GZIP 编码等的所有细节。这使得实际的客户端代码非常简洁，并有助于将其与一些服务器端更改隔离开来。

罗伊菲尔丁的 blog entry about HATEOAS之后有一个非常相关和有趣的讨论。