2013-10-09 119 views
13

在我的HTTP API中,其中一个端点应该返回一个随机生成的值,并且该值将与端点的已认证呼叫者相关联。目前,我有以下结构:空HTTP POST请求或GET请求通过HTTP API生成随机值

GET http://example.com/random-ticket HTTP/1.1 
Authorization: Basic base64-encoded-basic-auth-value 
Accept: application/json 
Host: example.com 

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Content-Type: application/json; charset=utf-8 
Date: Thu, 03 Oct 2013 07:25:56 GMT 
Content-Length: 59 

{"user-ticket":"Pfa42634e-1a2e-4a7d-84b9-2d5c46a8dd81"} 

发出GET请求以检索随机值。但是,HTTP GET calls should be idempotent和我上面的实现不符合该规则。另一方面,我不确定是否可以发出带有空邮件正文的HTTP POST请求。

什么是HTTP电子书执行这类操作的正确方法吗?

回答

15
  • 安全=>是否在状态的服务器上的一个变化的通话效果。
  • Idempotent =>多个调用是否导致服务器发生相同的更改。

所以,问题不在于返回的数据。相反,它是服务器状态:因此,如果将此值存储在服务器上,则会导致状态发生更改,则不适合GET。否则,如果它是返回的数据,那很好。如果拨打10分钟,拨打http://stackoverflow.com将返回不同的数据。

让我们来看另一个例子,时钟服务它返回当前时间。每次拨打电话时,您都会得到不同的值,但由于时钟状态是分开维护的,因此呼叫本身不会导致服务器上的状态发生变化。所以在这里使用GET是一个不错的选择。

+0

创建资源!=在服务器上存储值 –

+0

@FilipW我没有说存储一个值。它是**改变状态**。 – Aliostad

+0

谢谢你们。这个答案更具描述性,消除了我所有的困惑。 – tugberk

11

HTTP中绝对没有禁止使用空的主体的POST。

而且,消息携带一个表示,它是body + headers。在你的案例身体是0长度,这很好,并标识用户的头。

看到这里的讨论 - http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0273.html

+0

对不起,我提到了混乱的GET!但问题是这里没有提到的服务器状态是关键。 – Aliostad

+0

我认为OP很清楚他不应该在这里使用GET,所以我试图解释他为什么不应该害怕使用POST来代替 –

+0

我不太确定。 – Aliostad

1

在这种情况下,您应该使用POST,因为通过设计,可以缓存GET调用。关于空岗位,没有问题。类似的场景也被在讨论:POST with empty body,其中一个交提到:

没有内容长度和没有身体POST等同于用Content-Length的一个POST:以下0和任何结果,如能完全例如,当你上传一个空文件时就会发生。资源由URL决定,服务器必须知道如何处理主体,包括是否为空。我没有在这里看到其实这个问题: -/

威利

+2

“GET调用可以被缓存”这是正确的,但取决于您想要实现的数据一致性,即服务器上数据更改的频率。所以你也可能有GET请求,你不想允许缓存。此外,请考虑一定不要缓存的验证数据。所以你的缓存参数并不适合这里。 – brazo

+2

您可以返回适当的缓存标头。 – Aliostad

4

存在具有与获得一个随机数发生器,因为是没有存储服务器的状态没有问题。以同样的方式,你可以有一个计算器接受参数,并在调用GET时添加它们。关于可缓存的问题是一个有趣的问题,但并不真正适用于随机生成器,因为本质上的资源没有被缓存。这仍然不能改变它可以以安全/幂等方式设计的事实。

至于没有身体的POST,或者甚至在查询字符串中使用参数,这很好。 POST的关键在于它可能会导致服务器发生变化。它不会保证它会,但你不能认为它不会像GET一样。无论是否设置了任何内容,都不会改变可能发生变化的事实。例如想象一个虚构的资源“\ counter \ increment”。每次发布它时,都会导致\ counter增加。我没有发送任何有效负载,但是我导致了服务器状态的变化,因此它应该是POST或PUT。