我试图澄清一个与 REST 可发现性相关的概念——即是否满足 RESTful 服务的 HATEOAS 约束意味着现在 URI 可以更改,因为它们是可发现的并且没有记录。
这似乎没有遵循酷 URI的概念——URI永远不会改变的事实。它也与网络本身的模型有些不一致(REST 本质上应该非常适合)——URL 是可收藏的并且永远不会改变的事实,以及一旦你学会了一个,你就可以直接进入它并且你做的事实不必每次都经过根目录并发现它。
对此的任何反馈表示赞赏。
我试图澄清一个与 REST 可发现性相关的概念——即是否满足 RESTful 服务的 HATEOAS 约束意味着现在 URI 可以更改,因为它们是可发现的并且没有记录。
这似乎没有遵循酷 URI的概念——URI永远不会改变的事实。它也与网络本身的模型有些不一致(REST 本质上应该非常适合)——URL 是可收藏的并且永远不会改变的事实,以及一旦你学会了一个,你就可以直接进入它并且你做的事实不必每次都经过根目录并发现它。
对此的任何反馈表示赞赏。
对于很酷的 URI,不 - 你永远不应该更改它们。它们是您系统的入口点。但是,如果您希望能够在未来发展系统的其余 URI 结构,那么您应该拥有很少的这些。
对于任何非酷 URI,它们确实可以随时间变化。我最近写了一篇关于这个主题的博客文章,因为我发现 REST 能够让我随着时间的推移改进我的系统非常有用。
确保您的 API 文档阐明了这样一个事实,即您系统中只有少数酷 URI 应该由客户端硬编码,并且任何其他 URI 都应该在运行时通过超媒体遍历发现。把它们想象成一个 C 指针地址:没有人会关心指针变量的十六进制值是什么,但他们肯定希望它指向内存中的有效位置。您的非酷 URI 也是如此 - 它们的结构无关紧要,但它们是在运行时通过与您的服务器的对话检索到的这一事实使它们有效。
必须有文档。MediaTypes 和 Link Relations 是一个耦合点,客户端和服务器都必须理解这一点。这就是 HTML、ATOM 和 RSS 有标准的原因。
在运行时功能方面,我可以看到没有文档。我不需要知道雅虎主页上有什么,因为我可以发现。就像我服务的客户不需要知道我发布的新功能一样。他们可以找到链接存在,然后使用链接关系来查看它的作用。
所以文档是围绕要使用的标准和协议,而不是应用程序如何运行本身