REST 请求的 GET 或 PUT [英] GET or PUT for a REST request

查看:59
本文介绍了REST 请求的 GET 或 PUT的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我遇到过这样的情况,客户端应用程序可以请求匹配特定条件的资源,如果匹配的资源不存在,则会创建并缓存它.对相同条件的后续请求将返回缓存的资源.

I've got a situation where a client app can ask for a resource matching certain criteria, and if a matching resource does not exist it is created and cached. Subsequent requests for the same criteria will return the cached resource.

我可以通过 PUT 请求来实现这一点,以创建资源和后续的 GET.但是,在我的特定场景中,需要客户端对我的系统的内部工作了解太多,即客户端不应该关心资源是否已经存在.

I could implement this via a PUT request to create the resource and subsequent GETs. However, in my particular scenario that requires the client to know too much about the internal workings of my system i.e. the client shouldn't care whether the resource already exists or not.

如果资源不存在,那么允许客户端发出一个碰巧创建资源的单个 GET 请求是否是 ReSTful?

So is it ReSTful to allow the client to make a single GET request that happens to create the resource if it doesn't already exist?

推荐答案

理论上 GET 应该只是 GET,而不是改变你的系统状态.请参阅幂等性.

Theoretically GET should just GET, and not change the state of your system. See idempotency.

来自维基百科的段落:

某些方法(例如 HEAD、GET、OPTIONS 和 TRACE)被定义为安全的,这意味着它们仅用于信息检索,不应更改服务器的状态.

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server.

但是,在您的场景中,初始 GET 正在设置一个纯粹用于缓存的资源.后续调用不会改变系统的状态,因此我建议在这种情况下使用 GET.

However, in your scenario an initial GET is setting up a resource purely for caching. Subsequent calls won't change the state of the system, so I'd suggest that GET is fine in this scenario.

这篇关于REST 请求的 GET 或 PUT的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆