我遇到过这样一种情况，客户端应用程序可以请求匹配特定条件的资源，如果匹配的资源不存在，则会创建并缓存它。对相同条件的后续请求将返回缓存的资源。
我可以通过 PUT 请求来实现这一点，以创建资源和后续的 GET。但是，在我的特定场景中，它需要客户对我的系统的内部运作了解太多，即客户不应该关心资源是否已经存在。
那么，如果资源不存在，允许客户端发出一个碰巧创建资源的单个 GET 请求是 ReSTful 吗？
【问题讨论】：
标签： rest
理论上 GET 应该只是GET，而不是改变系统的状态。见idempotency。
来自维基百科的段落：
某些方法（例如，HEAD、GET、OPTIONS 和 TRACE）被定义为安全的，这意味着它们仅用于信息检索，不应更改服务器的状态。
但是，在您的场景中，初始 GET 设置纯粹用于缓存的资源。后续调用不会改变系统的状态，所以我建议在这种情况下使用 GET 就可以了。
【讨论】：
为此目的使用 GET 是绝对合适的；资源的“渲染”超出了客户端/服务器 HTTP 交互的范围，因此它是否“创建”实际上并不重要——这是统一接口之外的实现问题。
我的意思是这对客户来说并不重要——因为就它而言，请求是安全的+幂等的。它不关心服务器是否出于效率原因正在创建一些内容以即时返回，或者它是否“已经存在”并且只是输出。
GET /resource?criteria1=xyz&criteria2=abc
【讨论】：
是的，如果创建资源的唯一目的是缓存它。 这样，您可以认为您的系统已经包含所有可能的 GET 结果，并且没有违反幂等性。机器如何获得结果（来自缓存或通过您的算法）并不重要，甚至是无趣的。
Richard Ev：如果您这么严格，您甚至无法将 GET 请求记录到您的服务器，因为记录是一种副作用，会改变系统的状态。 编辑：我看到你不再那么严格了，我同意:-)
【讨论】：
当你获取一些数据时使用 GET，当你改变一些状态时使用 POST。
如果您使用 GET 更改某些状态，并且如果您的应用在 Internet 上，搜索引擎抓取可能会对您的系统产生不良影响。
此外，GET 请求由浏览器缓存，因此您可以节省一些带宽和服务器资源，以防数据更改不那么频繁。
【讨论】：