Fielding 在他的博客文章REST API 必须由超文本驱动中写道：
REST API 不应该依赖于任何单一通信协议，尽管它到给定协议的成功映射可能取决于元数据的可用性、方法的选择等。一般来说，任何使用 URI 进行标识的协议元素都必须允许使用任何 URI 方案来进行识别。 [这里的失败意味着识别与交互没有分离。]
根据我的阅读，任何 REST API 都必须支持多个协议才能被认为是 RESTful。
如果应用程序只支持一种协议（例如 HTTP），那么满足所有其他条件的应用程序是否会被认为是安全的？
根据我的阅读，任何 REST API 都必须支持多个协议才能被认为是 RESTful。
我认为这不是正确的阅读方式。
回想一下，Web 是 REST 架构风格的参考实现。大多数标识符都是 https/http；但我们还可以找到 ftp、mailto 和 about。 Fielding 的观点是，为了识别资源，我们的机制应该与方案无关。
任何使用 URI 进行标识的协议元素必须允许使用任何 URI 方案来进行标识。 （强调）
我们有一个整个注册表充满了URI方案，并且为了识别资源，它们都具有平等的地位。
Link: <mailto://[email protected]>; rel="author"; anchor="https://stackoverflow.com/questions/73654298/is-a-rest-api-supposed-to-support-multiple-protocols"
这是一个完美的链接关系，表明两个资源之间存在作者关系。
Fielding n't 意味着 Web 服务器也必须是邮件服务器；或者当您将 mailto URI 放入图像标签时，浏览器需要弄清楚您的含义。
回顾菲尔丁的后续文章，专业化：
可能会有所帮助我的论文是写给特定读者的：软件工程和网络协议设计领域的专家......
Fielding 为 HTTP 1.1 机器对机器通信设计了 REST。它有很多限制：https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htmAfaik。只有 HTTP 可以满足所有这些要求，即使您使用 HTTP，也必须以特定的方式使用它。虽然我对其他协议不太了解。可以肯定的是，您不能将 REST 用于 Websocket，因为通信是有状态的，并且违反了无状态约束。