我看过的各种讲座以及我在REST上扫描的教程似乎都在强调一种称为“可发现性”的东西。据我有限的理解，该术语似乎意味着客户应该能够http://URL-自动获得其可以做的事情的清单。
我难以理解的是-“软件客户”不是人类。它们只是程序，没有直观的知识来理解与所提供的链接的确切关系。只有人可以访问网站并理解所显示的文本和链接并对其进行操作。
那么，当访问此类可发现URL的客户端代码实际上无法对其进行任何操作时，除非客户端的人工开发人员实际尝试了所提供的资源，可发现性的意义何在？这看起来与在《文档》手册中定义可用功能集完全一样，只是方向不同，实际上需要为开发人员进行更多工作。为什么第二种预定义可以在实际REST资源外部的文档中完成的工作的方法被认为是次等的呢？
Answers:
对可发现性的需求可能并不重要，但是允许可发现性的链接可用于更多目的。在我看来，其中最重要的是，在对客户端的响应中提供完整的URI，这意味着没有客户端将需要“编写” URI。这意味着没有客户会需要有关URI的结构的知识。这样一来，服务器开发人员就可以在适合自己的情况下更改URI方案，因为他们无需考虑较旧的客户端，仍然依赖于旧的URI构造方法。
“客户端”的高级程度可能不足以使用它，但是客户端的用户可以。毕竟，客户端可以像网络浏览器一样简单。可发现性在于使人们能够学习和使用API。
例如，Jenkins（CI服务器）具有类似REST的界面。转到任何页面，在URL后面加上“ / api”，您将获得一个页面，描述您可以做的所有事情。它使学习API变得很简单。例如，http: //ci.jruby.org带您到jenby的jenkins服务器，而http://ci.jruby.org/api带您到该特定页面的api。
前一阵子，我很高兴使用一个API，该API的文档非常非常难以理解。
一旦我设法从服务器获得实际答复，就可以将文档与服务器答复进行比较，并使用它来解密文档（是的，解密它是正确的术语）。问题是，如果根据规范发送到服务器的请求不完全正确，您将得到一个错误，并且由于文档不可读，弄清楚如何发送正确的请求几乎是不可能的。API文档也有不同的版本，它们彼此之间可能并不相同，并且可能与API本身并不相同。那没有帮助。
如果有一个命令可以发送到服务器，返回所有可能命令的列表以及如何精确发送这些命令，那将非常有帮助。可发现性不仅对于客户而言，对软件开发人员也很有用。
注意：我不是该主题的专家，但是几年前我经历了类似的过程，试图调和人们对“ REST”的不同细微差别，这是我从研究这个问题中获得的收获。时间。
据我了解，这源于Roy Fielding的超媒体，它是应用程序状态的引擎，又称“ HATEOAS”，后来成为“语义网”思想的推动者。
所以...基本上，据我所知，您可以使RESTful应用程序基本上是自我描述的，这样，消费者就不必具有使用正式合同即可使用您的内容/功能。他们能够从一些默认的根终结点开始使用，然后在消费者交互时浏览您的应用程序提供的上下文相关链接。消费者当然可以是个人或系统性代理商。
如果您只是将“ REST”用于映射到CRUD操作的漂亮URL，那么消费者必须根据众所周知的合同对其进行事先了解并进行调用，因此Roy Fielding认为它不是真正的RESTful。
这并不是说REST风格的RPC服务设置不是有用的，它不是对更复杂的RPC模型的改进，并且适合于有限/受控的使用，但是强硬派会对此视而不见并认为它已经退化/不是真正的REST。