RESTful API运行时可发现性/ HATEOAS客户端设计

对于我参与的SaaS创业公司，我在不同平台上构建了一个REST风格的Web API和几个客户端应用程序。我想我已经找到了API，但现在我正在转向客户。正如我一直在阅读有关REST，我看到REST的一个关键部分是发现，但似乎有很多争论什么发现的两种不同的解释之间的真正含义是：RESTful API运行时可发现性/ HATEOAS客户端设计

开发发现：开发人员将大量的API详细信息硬编码到客户端，例如资源URI，查询参数，支持的HTTP方法以及他们通过浏览文档并试用API响应发现的其他详细信息。这种类型的发现恕我直言，需要冷静的联系和API版本问题，并导致客户端代码与API的硬耦合。看起来，如果使用一个记录良好的RPC集合，这并没有什么好处。
运行时发现 - （大概只有一个媒体类型与API交易的知识）的客户端应用程序本身能够计算出它与外的带很少或没有信息需要的一切链接可以很热。但为了使API非常高效，似乎需要大量用于查询参数的链接模板，这使得带外信息蠕动回来了。可能还有其他困难，我还没有想过，因为我没有在开发中得到了这一点。但我确实喜欢松耦合的想法。

运行时发现似乎是REST的圣杯，但我看到关于如何实现这样的客户端的小小讨论。几乎所有我发现的REST源似乎都假定开发人员发现。任何人都知道一些运行时发现资源？最佳实践？具有真实代码的示例或库？我正在为一个客户端开发PHP（Zend Framework）。 Objective-C（iOS）。

运行时发现是一个现实的目标，考虑到开发人员社区中现有的工具和知识集？我可以写我的客户端以不透明的方式处理所有的URI，但如何最有效地做到这一点是一个问题，尤其是在低带宽连接上。无论如何，URI只是等式的一部分。运行环境中的链接模板怎么样？除了提出大量的OPTIONS请求外，如何沟通支持哪些方法？

来源

2012-02-09 curtisdf

只是稍微放在您的OPTIONS参考。您可以使用“允许”标头在OPTIONS请求之外传递允许的资源操作。 Roy Fielding甚至将头文件视为一种超文本形式 - 参见[这里]（http://tech.groups.yahoo.com/group/rest-discuss/message/14432）。 – paulkmoore 2012-05-19 14:37:59

tats一个gr8的问题，关键问题给出的适用方法的列表，客户应该能够形成常规CRUD操作的URL或将被称为“带外”？说，如果我们也为CRUD操作提供链接，那么你如何在json中做“形式”？可能是如果你使用应用程序特定的媒体类型，你不需要做“表单”，但是wat是发现媒体类型的标准方式（即json模式），发现模式的过程是否会被视为“out-of-乐队“为客户？ – redzedi 2012-07-29 08:06:23

xhtml看起来非常好，流畅，但如果你必须做json，我想现在是非常不稳定 – redzedi 2012-07-29 08:07:47

在此视频中，Jon Moore使用运行时HATEOAS自动发现构建了一个通用客户端。这是非常令人印象深刻，非常值得关注：

http://oredev.org/oredev2010/2010/sessions/hypermedia-apis.html

来源

2012-02-09 22:07:43

是否可以在某处使用“客户端”src代码？我没有看到任何客户端代码，他只是在java示例中使用他的客户端 – Denny1989 2015-06-26 10:36:51

@ Denny1989我认为这是源代码：https：//github.com/cimlabs/hypermedia-client-java – dbank 2016-01-05 17:00:50

你做了你的家庭作业，你到了它的核心：运行时发现是圣杯。不要追逐它。

告诉UDDI运行时发现的凄美的故事：http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

来源

2012-02-09 01:52:03

这绝对是一个难啃的骨头。在谷歌，我们已经实施了我们的发现服务，我们所有的新API都是针对它们而构建的。 TL; DR版本是我们生成的JSON模式样规格，我们的客户可以解析 - 其中许多是动态的。

这样的结果意味着开发人员可以更轻松地进行SDK升级，并且对我们来说更容易/更好的维护。

绝不是完美的解决方案，但我们的许多开发人员似乎都喜欢。

见link更多细节（并确保观看VID）

来源

2012-02-09 02:19:36 jonathanberi

是否有任何标准为我们自己的API实现这样的发现服务？ – 2014-12-21 18:20:40

引人入胜。你所描述的基本上是HATEOAS原理。你问什么是HATEOAS？阅读此：http://en.wikipedia.org/wiki/HATEOAS

通俗地说，HATEOAS意味着链接跟随。这种方法将您的客户从特定的URL中分离出来，并且使您可以灵活地更改您的API而不会破坏任何人。

来源

2012-02-09 06:01:36 Sam

感谢您提醒我关于HATEOAS。这似乎是我想知道如何处理客户端界面的关键字。（男人，我真的不喜欢这个缩写！）我之前遇到过HATEOAS，我想我内化了它的意思，但是我忘记了在我的搜索中使用这个名字。现在我看到很多资源正在给我提供更好的照片，并且有些人希望这毕竟无法实现。 – curtisdf 2012-02-09 17:14:05

ios示例？你选择了什么？在某些时候，你需要知道你在找什么！所以你需要知道API，所以你需要硬编码一些东西！ – Vassily 2012-09-27 13:21:11

@curtisdf完全脱离主题，但不是说你真的不喜欢它，应该说你恨 - 它...恨 - OAS ... :)对不起，无法抗拒 – jamiebarrow 2013-02-18 21:00:59

我想HATEOAS重要的一点不在于它是一些圣杯的客户端，但它隔离URI改变客户端 - 假设您正在使用已知（或开发者发现的自定义）链接关系，这将允许系统知道对象的哪个链接是可编辑的表单。重要的一点是使用可识别超媒体的emdia类型（例如HTML，XHTML等）。

来源

2012-12-11 15:32:46 Falkayn

有关基本运行时发现客户端的另一个示例，请查看HAL Talk Hypermedia API client demo。

基于超文本应用程序语言（XML链接+ JSON模式）：http://stateless.co/hal_specification.html

来源

2013-07-25 14:16:33 papercowboy

你写：

为了使API非常有效，查询参数很多链接模板似乎是必要的，这使得出的带外信息爬回去。

如果该链接模板在之前请求提供，那么就没有了带外信息。例如，HTML搜索表单使用链接模板（/search?q=%@）来生成URL（/search?q=hateoas），但除了如何使用HTML表单和GET以外，客户端（网络浏览器）不知道任何内容。

来源

2013-08-06 15:03:26

的确没有任何客户端代码，带外信息 - 客户端负责使用提供的资源/实例数据扩展uri模板（并且应该知道如何执行此操作） - http://json-schema.org/latest/json-schema-hypermedia。 HTML＃anchor18 – fusi 2016-01-12 14:12:05

在您调用API'RESTful'之前应该满足的一个要求是应该可以在该API之上编写一个通用客户端应用程序。使用通用客户端，用户应该能够访问所有API的功能。通用客户端是一种客户端应用程序，它不会假定任何资源具有超出媒体类型定义的结构的特定结构。例如，Web浏览器是知道如何解释HTML的通用客户端，包括HTML表单等。

现在，假设我们为Web商店提供了HTTP/JSON API，并且我们要构建HTML/CSS/JavaScript客户端，为我们的客户提供卓越的用户体验。让客户成为通用客户端应用程序会是一个现实的选择吗？不可以。我们希望为每个特定的数据元素和每个特定的应用程序状态提供特定的外观和感觉。我们不希望在API中包含关于这些表示特定信息的所有知识，相反，客户应该定义外观和风格，并且API应该只携带数据。这意味着客户端将特定资源元素与特定布局和用户交互进行了硬编码耦合。

这是HATEOAS的结束，因此REST的结束？ 是和不是。

是，因为如果对API到客户端，我们硬编码的知识，我们失去HATEOAS的好处：服务器端更改可能会破坏客户端。

没有，原因有二：

作为 “REST风格” 是API的一个属性，而不是客户端的。只要有可能，理论上是，要构建一个提供API所有功能的通用客户端，可以将该API称为RESTful。客户不遵守规则的事实不是API的错。通用客户端会有糟糕的用户体验这一事实不是问题。为什么知道它很重要可能有一个通用客户端，如果我们实际上没有那个通用客户端？这使我想到第二个原因：
RESTful API为客户提供了选择他们想要的通用性的选项，即他们希望如何适应服务器端更改。需要提供良好用户体验的客户仍然可以灵活地修改URI更改，更改默认值等等。在没有用户交互的情况下完成批量作业的客户可能会对其他类型的更改具有弹性

如果您对实际例子感兴趣，请检查我的JAREST paper。最后一节是关于HATEOAS。你会发现，在JAREST中，即使是高度交互式和具有视觉吸引力的客户端，也可以对服务器端更改产生相当的弹性，但不是100％。

来源

2015-11-02 11:15:50

RESTful API运行时可发现性/ HATEOAS客户端设计

回答

相关问题