【发布时间】：2019-11-22 15:25:03
【问题描述】：
下面的查询 URL/端点似乎成功地向 API 资源发出请求并返回 JSON 响应：
鉴于请求不仅由 URL 组成，还由方法、标头和正文组成，有人可以解释一下 API 如何知道要使用哪种方法，以及标头和正文是如何传输的（如果它们确实存在）？
【问题讨论】：
-
“标题和正文如何传输”：tools.ietf.org/html/rfc7231
【发布时间】：2019-11-22 15:25:03
【问题描述】：
鉴于请求不仅由 URL 组成，还由方法、标头和正文组成，有人可以解释一下 API 如何知道要使用哪种方法，以及标头和正文是如何传输的（如果它们确实存在）？
如果我正确理解您的问题... API 不知道这些事情，客户端知道这些事情。
也就是说，当我在网络浏览器中查看您的问题时，我真正看到的是网络浏览器对 HTML 文档的解释。因为网络浏览器使用 HTML，它知道<a href="..."> 的含义；引用的文本是我可能想要导航到的另一个资源的标识符。
浏览器也知道 RFC 3986，所以它知道如何解析引用的字符串并从中提取协议、主机和目标 uri。
因为浏览器也知道 https，所以它知道在未指定端口时应该默认使用哪个端口号。
因为浏览器知道 HTTP，它知道如何构造一个有效的 HTTP 请求，以及它可能想要附加的必需和可选标头的语义。
由于 HTTP 遵循 REST 架构风格，我们也知道接口是统一的——所有 HTTP 资源使用相同的语义。所以浏览器不需要知道标识符是什么，就能知道GET、HEAD、OPTIONS都是安全的。同样，身份验证、缓存、内容协商等规则都是相同的，因此浏览器可以在生成请求时制作适当的标头。
例如，浏览器知道它自己支持 HTML，因此它包含的标头传达了对资源的 HTML 或 XHTML+xml 表示形式的偏好（如果有的话）。
如果我改为切换到命令行，我可以改用curl(1) 来生成 http 请求，这将生成具有不同标头的 HTTP 请求。
浏览器（和 curl）知道不发送带有 HEAD 或 GET 请求的正文，因为 HTTP 规范解释了 GET 或 HEAD 请求的有效负载没有定义的语义。
在对话的 API 端，服务器了解 HTTP，因此知道如何正确解释 HTTP 请求的字节。因此，服务器知道在哪里查找 HTTP 方法的请求、目标 URI、可能（或可能不会）修改请求上下文的标头，等等。然后，实现可以使用该信息做任何它喜欢的事情，并构造一个合适的 HTTP 响应（实际上，将元数据提升到响应的标头中，以表示参与对话的所有通用组件都可以理解。
【讨论】：