REST 可发现性和 HATEOAS 是否意味着您可以更改 URI？
我试图澄清一个与 REST 可发现性相关的概念 - 即是否满足 RESTful 服务的 HATEOAS 约束意味着现在 URI 可以更改，因为它们是可发现的并且没有记录。
这似乎不遵循 Cool URI 的概念 - 事实上 URI 不永远不会改变。它也与 Web 本身的模型（REST 本质上应该完美契合）有些不一致——事实上，URL 是可添加书签的并且永远不会改变，而且一旦你学会了一个，你就可以直接访问它并且你可以这样做。不必每次都深入根源并发现它。
对此的任何反馈都将受到赞赏。
I'm trying to clarify a concept related to REST discoverability - that is whether or not satisfying the HATEOAS constraint for a RESTful service means that now the URIs can change, because they are discoverable and not documented.
That seems to not follow the concept of Cool URIs - the fact that URIs don't change, ever. It is also somewhat uncongruent with the model of the web itself (which REST should essentially fit perfectly) - the fact that URLs are bookmarkable and never change, and the fact that you once you learn one, you can go directly to it and you do not have to go through the root and discover it each time.
Any feedback on this is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于 Cool URI，不可以 - 您永远不应该更改它们。它们是您系统的入口点。但是，如果您希望将来能够改进系统 URI 结构的其余部分，那么您应该只使用很少的这些。
对于任何非 Cool URI，它们确实可以随着时间的推移而改变。我最近写了一篇关于这个主题的博客文章，因为我发现 REST使我能够随着时间的推移改进我的系统，使其变得非常有用。
确保您的 API 文档阐明这样一个事实：您的系统中只有少数几个 Cool URI 应该由客户端进行硬编码，任何其他 URI 都应该在运行时通过超媒体遍历来发现。将它们想象成 C 指针地址：没有人会关心指针变量的十六进制值是多少，但他们肯定希望它指向内存中的有效位置。对于非 Cool URI 也是如此 - 它们的结构并不重要，但事实上它们是在运行时通过与服务器的对话检索的，这使得它们有效。
For Cool URIs, no - you should not change them, ever. They are the entry points into your system. However, you should have very few of those if you want to have the ability to evolve the rest of your system's URI structure in the future.
For any non-Cool URIs, they can indeed change over time. I recently wrote a blog post about this topic because I find REST's ability to allow me to evolve my system over time to be incredibly useful.
Make sure your API documentation spells out the fact that only the few Cool URIs in your system should be hard-coded by clients, and any other URI should be discovered at runtime through hypermedia traversal. Think of them like a C pointer address: nobody would care what the hex value of a pointer variable is, but they sure as heck would want it to point to a valid place in memory. Same goes for your non-Cool URIs - their structure doesn't matter, but the fact that they were retrieved at runtime through conversations with your server makes them valid.
必须有文档。媒体类型和链接关系是一个耦合点，客户端和服务器都必须理解这一点。这就是 HTML、ATOM 和 RSS 拥有标准的原因。
就运行时功能而言，我发现没有文档。我不需要知道雅虎主页上有什么，因为我可以发现它。就像我的服务客户不需要了解我发布的新功能一样。他们可以找到链接存在，然后使用链接关系来查看它的作用。
因此，文档围绕要使用的标准和协议，而不是应用程序本身如何运行
There has to be documentation. MediaTypes and Link Relations are a coupling point and both the client and the server must understand that. That's why HTML, ATOM and RSS have standards.
In terms of runtime functioning I can see not having documentation. I don't need to know what Yahoo has on it's home page because I can discover that. The same way a client of my service doesn't need to know about a new feature I release. They can find the link exists and then use the link relation to see what it does.
So the documentation is around the standards and protocol that are to be used, but not how the application will function itself