想象一下启动一个长时间运行的进程的请求,其输出是一大组记录。如何设计一个REST API来获取一个大的(临时的)数据流?
我们可以用一个POST请求启动该进程:
POST/API/V1 /长计算
输出包括编号记录的大序列,必须发送给客户。由于输出很大,服务器不存储所有内容,因此维护窗口大小上限的记录窗口。假设它可以存储多达1000条记录(并且只要这些记录可用,就会暂停计算)。当客户端获取记录时,服务器可能会随后删除这些记录,并继续生成更多记录(因为1000长度窗口中的更多插槽是免费的)。
比方说,我们取得与记录:?
GET/API/V1 /长计算ACK = 213
我们可以利用这意味着服务器将返回从开始记录索引214.当服务器接收到这个请求时,它可以假定(行为良好)客户端确认客户端收到213号的记录,所以它删除它们,然后将记录从214开始返回到任何当时可用。
下,如果客户端请求:
GET/API/V1 /长计算ACK = 214
服务器将删除记录214和返回记录从215
开始?这似乎是一个合理的设计,直到发现GET请求需要安全且幂等(请参见HTTP RFC中的第9.1节)。
问题:
- 有没有更好的方式来设计这个API?
- 即使它看起来违反了标准,它仍然可以保持为GET吗?
- 难道是合理,使之POST请求如:
POST/API/V1 /长计算/截断和取ACK = 213
2616已过期。请改用RFC 723x。 –
我与@Evert和@EricStein其他协议/样式可能更适合。尽管如此,HTTP为每个客户端返回相同输出的数据提供了一个简洁的流式解决方案 - [部分GET请求](https://tools.ietf.org/html/rfc7233)。虽然RFC或多或少地解释了字节范围,但像“Content-Range:”项目21-40/*“这样的自定义范围也是可能的,尽管您会错过确认。这必须以不同的方式完成。请注意,如果服务器能够为每个客户端计算相同的结果段,则服务器不需要存储整个结果 –
@RomanVottner范围可以工作,但API仍然需要处理所请求范围尚未填充的情况,以及如何安全删除记录,以便创建更多记录。 –