对于提供提供主键的资源的下载的端点，正确的HTTP谓词是什么？

简单地说，GET语义通常是您想要使用的。

request方法令牌是请求语义的主要来源；它指示客户端提出此请求的目的以及客户机对成功结果的期望。RFC-7231；第4.1节

GET方法请求传输目标资源的当前选定表示形式。GET是信息检索的主要机制，几乎是所有性能优化的重点。因此，当人们谈到通过HTTP检索一些可识别的信息时，他们通常指的是发出GET请求。RFC-7231；第4.3.1节

资源由URI标识；下面的两个请求针对不同的资源：

代码语言：javascript运行复制GET /example?uuid=764baee2-c5be-49cc-ac83-c9d1ea61d68a HTTP/1.1

GET /example?uuid=3b90b949-911c-433c-bec4-e6063f5377e0 HTTP/1.1从REST的角度来看，尽管底层实现(也称为“端点”)可能是相同的，但它们是不同的。

您可以将URI本身看作是用于在文档存储中查找资源的键。

更常见的做法是，我们将使用某种形式的模板从目标uri中提取我们在服务器上访问数据所需的特定信息--例如，从查询部件中提取uuid参数并将其用作主键。

这是理想的设置:如果请求语义是有效只读，并且我们期望返回资源的表示(例如，PDF)，那么GET就是我们想要的方法。

有时情况并不理想:当我们需要请求体中包含的信息来做正确的事情时，就会出现这种情况。在HTTP中，GET请求上的有效负载(消息体)具有无定义语义。因此，如果您需要在请求中有一个主体，那么GET就超出了范围，您可能会使用POST。

在实践中发现了对请求行长度的各种特殊限制。建议所有HTTP发送器和收件人至少支持8000辛特的请求行长度。RFC-7230；第3.1.1节

除非您控制客户端，否则您可能无法确保支持8000 octets。因此，您通常会得到一个更简单的资源标识符，并将大量信息编码到消息体(如肥皂或GraphQL)中，并将POST作为请求方法，因为其他方法的语义不合适。

这并不理想，因为类似于资源的PDF表示形式应该是可缓存的，但是HTTP缓存的语义不支持请求的消息主体必须是缓存键一部分的用例。请参阅诺丁汉2012-09-04