6
RESTful API运行时可发现性/ HATEOAS客户端设计
对于我参与的SaaS初创公司，我正在使用RESTful Web API和在使用它的不同平台上构建了几个客户端应用程序。我想我已经弄清楚了API，但是现在我转向客户。当我阅读有关REST的文章时，我发现REST的关键部分是发现，但是关于发现真正含义的两种不同解释之间似乎存在很多争论： 开发人员发现：开发人员将大量API详细信息硬编码到客户端，例如资源URI，查询参数，受支持的HTTP方法以及他们通过浏览文档并试验API响应而发现的其他详细信息。恕我直言，这种类型的发现需要很酷的链接和API版本控制问题，并导致客户端代码与API的硬耦合。似乎没有比使用有据可查的RPC收藏更好的了。 运行时发现-客户端应用程序本身能够以很少或没有带外信息（大概只有API所处理的媒体类型的知识）来找出所需的一切。链接可能很热。但是，要使API非常高效，似乎需要对查询参数进行大量链接模板处理，从而使带外信息重新出现。自从我还没有想到过，我可能还没有想到其他困难。在开发中达到了这一点。但是我确实喜欢松散耦合的想法。 运行时发现似乎是REST的圣杯，但是我很少看到有关如何实现这种客户端的宝贵讨论。我发现的几乎所有REST资源似乎都假定开发人员发现了。有人知道一些运行时发现资源吗？最佳做法？带有真实代码的示例或库？我正在使用PHP（Zend Framework）的一个客户端。另一个是Objective-C（iOS）。 考虑到开发人员社区中现有的工具和知识，运行时发现是否是一个现实的目标？我可以编写客户端以不透明的方式处理所有URI，但是如何最有效地执行此操作是一个问题，尤其是在低带宽连接上。无论如何，URI只是方程式的一部分。在运行时上下文中链接模板怎么样？除了发出大量OPTIONS请求外，如何交流支持哪些方法？