Tag: 讨厌的人

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

对于我参与的SaaS创业公司，我正在构build一个REST风格的Web API和几个客户端应用程序在不同的平台上使用它。 我想我已经知道API了，但现在我正在转向客户。 正如我一直在阅读关于REST的内容，我发现 REST的一个关键部分是发现 ，但是在两种不同的发现真正含义的解释之间似乎有很多争论： 开发人员发现 ：开发人员将大量的API详细信息硬编码到客户端，例如资源URI，查询参数，支持的HTTP方法以及他们通过浏览文档并试用API响应发现的其他详细信息。 这种types的发现恕我直言，需要冷静的联系和API版本问题，并导致客户端代码硬耦合到API。 看起来好像使用一个logging良好的RPC集合，这并没有什么好处。 运行时发现 – 客户端应用程序本身能够在很less或没有带外信息的情况下找出所需的一切（大概只有API处理媒体types的知识）。链接可能很热。 但是，为了使API非常高效，似乎需要大量的查询参数的链接模板，这使得带外信息变得复杂起来。还有其他的困难，我还没有想到，因为我没有在发展中得到了这一点。 但我喜欢松耦合的想法。 运行时发现似乎是REST的圣杯，但我看到了关于如何实现这样的客户端的小小的讨论。 几乎所有我发现的REST源似乎都假定开发人员发现。 任何人都知道一些运行时发现资源？ 最佳实践？ 具有真实代码的示例或库？ 我正在为PHP客户端（Zend Framework）工作。 Objective-C（iOS）的其他。 鉴于开发人员社区中现有的工具和知识，运行时发现是一个现实的目标吗？ 我可以写我的客户端以不透明的方式处理所有的URI，但如何最有效地做到这一点是一个问题，尤其是在低带宽连接上。 无论如何，URI只是等式的一部分。 那么运行时环境中的链接模板呢？ 除了提出大量的OPTIONS请求之外，如何沟通支持哪些方法？

HATEOAS的实例（REST架构）

正如大家可能已经注意到的那样，在野外有很多假的/基本的REST-API（它实现了一个HTTP-API并称之为REST，而没有遵循超文本作为引擎的应用程序状态要求，着名的罗伊·T·菲尔丁（Roy T. Fielding ）的咆哮，他是第一个指定REST范式的人）。 我一直无法find任何真正的超文本驱动的REST实现的实例，以及与状态转换相关的特定于应用程序的媒体types定义。 有这样的实现的公共可访问的例子吗？