HATEOAS运行时可发现性/ RESTful客户端设计
对于我参与的一家SaaS初创公司，我正在构建一个RESTful web应用程序接口和几个使用它的不同平台上的客户端应用程序。我想我已经弄清楚了API，但现在我转向了客户端。由于我一直在阅读关于REST的文章，我看到REST的一个关键部分是发现，但对于发现真正意味着什么，似乎有两种不同的解释之间存在很多争论：
HTTP ：开发人员将大量的
- Developer细节硬编码到客户端中，例如资源URI、查询参数、支持的方法，以及他们通过浏览文档和试验API的响应而发现的其他细节。这种类型的发现IMHO需要很酷的链接和API版本控制问题，并导致客户端代码与API的硬耦合。没有比使用RPC的it seems.
- Runtime discovery的文档化良好的集合更好的了-客户端应用程序本身能够在很少或没有带外信息的情况下计算出它需要的一切(假设只有对该API所处理的媒体类型的了解)。链接可以是热门的。但是，为了使API非常高效，似乎需要对查询参数进行大量的链接模板，这使得带外信息悄悄地返回。可能还有其他的困难我还没有考虑到，因为我还没有达到开发的那个阶段。但我确实喜欢松耦合的想法。
运行时发现似乎是REST的圣杯，但我看到关于如何实现这样一个客户端的讨论很少。我发现的几乎所有REST源代码似乎都假定开发人员发现。有人知道一些运行时发现资源吗？最佳实践？示例还是包含真实代码的库？我正在为一个客户使用PHP (Zend Framework)。另一组为Objective-C (iOS)。
考虑到开发人员社区中目前的一组工具和知识，运行时发现是一个现实的目标吗？我可以编写我的客户端以不透明的方式处理所有URI，但是如何最有效地这样做是一个问题，特别是在低带宽连接上。无论如何，URI只是方程式的一部分。运行时上下文中的链接模板又如何呢？除了发出大量的OPTIONS请求之外，传达一下支持哪些方法呢？
回答 6
Stack Overflow用户
发布于 2012-02-09 10:19:37
这绝对是一个很难解决的问题。在Google，我们已经实现了我们的Discovery服务，我们所有的新API都是基于它构建的。TL;DR版本是我们生成一个类似JSON Schema的规范，我们的客户可以对其进行解析--其中许多是动态解析的。
这意味着开发人员更容易升级SDK，对我们来说更容易/更好地维护。
这绝对不是一个完美的解决方案，但我们的许多开发人员似乎都喜欢。
有关更多详细信息，请参阅link (请务必观看视频)。
Stack Overflow用户
发布于 2012-02-09 14:01:36
令人着迷。您所描述的基本上就是HATEOAS原则。你问的HATEOAS是什么？请阅读：http://en.wikipedia.org/wiki/HATEOAS
在外行的术语中，HATEOAS意味着链接跟随。这种方法将您的客户端与特定的URL解耦，并为您提供了更改API的灵活性，而不会破坏任何人。
Stack Overflow用户
发布于 2012-02-09 09:52:04
你完成了你的家庭作业，并且达到了它的核心:运行时发现是圣杯。不要追逐它。
UDDI讲述了一个运行时发现的辛酸故事：http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
https://stackoverflow.com/questions/9204110
复制相似问题