下面的查询URL /端点似乎已成功向API资源发出请求并返回JSON响应：
鉴于请求不仅由URL组成，还由方法，标头和主体组成，有人可以解释一下API如何知道要使用哪种方法，以及标头和主体如何传输（如果确实存在）？
答案 0 :(得分：1)
鉴于请求不仅由URL组成，还由方法，标头和主体组成，有人可以解释一下API如何知道要使用哪种方法，以及标头和主体如何传输（如果确实存在）？
如果我正确理解了您的问题... API不了解这些内容，那么客户端就知道这些内容。
这就是说，当我在Web浏览器中查看您的问题时，我真正看到的是Web浏览器对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响应（实际上，将元数据以表示的形式提升到响应的标头中，参与会话的所有通用组件都可以理解该表示形式。