我创建了一个REST API，其端点以文件作为输入（例如Excel文件），从文件中提取所有电子邮件地址，并返回电子邮件地址列表。什么是最合适的HTTP动词用于此端点？在语义上，似乎GET是最佳选择，但在URL中传递文件数据似乎是一个坏主意。传递文件会更好POST，但POST意味着将创建一个数据库记录，并且该操作不是幂等的（它是）。
我意识到这是一个挑剔的语义问题，但其他人肯定会有同样的问题，所以希望答案是有用的。
答案 0 :(得分：1)
讨论有点迂腐，但我的2c是PUT。 PUT是一个幂等动词，意味着它只能在PUT的资源上运行。但是，RFC 2616表明服务器必须向结果发送301重定向。
来自RFC 2616
POST和PUT请求之间的根本区别体现在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是数据接受过程，某些其他协议的网关或接受注释的单独实体。相反，PUT请求中的URI标识请求附带的实体 - 用户代理知道URI的用途，服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于其他URI，
必须发送301（永久移动）响应;然后，用户代理可以自行决定是否重定向请求。
当然，正如朱利安如此礼貌地指出，RFC 2616已被RFC 2731淘汰，但没有提出这样的要求。
YMMV。实际上，只做对你有意义的事情似乎是有道理的。
答案 1 :(得分：1)
POST并不意味着幂等性，也不意味着创建数据库记录。
确实，如果 幂等并保存，那么不必使用POST会很好，但是现在，还没有更好的HTTP方法
答案 2 :(得分：0)
不要挂断电话。一旦做出决定，这就是一件无关紧要的事情。就个人而言，我会坚持发布任何不属于＆＃34; CRUD＆＃34;语义。哎呀，如果你正在设计一个SOAP或WCF服务，你可能不会考虑这个决定，这是我不太重视设计RESTful模型的一个原因，除非有特定的要求去做所以为了互操作。否则，我设计一个具有合理意义的服务合同的SOA，而不考虑它属于哪个传输动词。
答案 3 :(得分：0)
我认为PUT RFC中的关键句是：
A successful PUT of a given
representation would suggest that a subsequent GET on that same
target resource will result in an equivalent representation being
sent in a 200 (OK) response.
在您的用例场景中没有这样的期望（除非用户需要为每个不同的Excel输入不同的URL并保存每个响应）。它似乎很好地适用于数据处理资源＆＃34;在同一RFC中描述了POST。