ReST低延迟-上传未决时如何回复GET? [英] ReST low latency - how should I reply to a GET while an upload is pending?

问题描述

我正在设计一个 ReST API，该API遵循基本的

I am designing a ReST API which follows the basic CRUD pattern.

我的API可以收到更新资源的请求，这可能需要很短的时间来处理.理想情况下，我想通知客户新版本即将发布，并且我缓存的版本实际上何时到期还存在一些不确定性.

My API can receive a request to update a resource which may take a short time to process. Ideally I would like to inform clients that a new version is about to be available and that there is some uncertainty over when the version I have cached actually expires.

因此，我打算在过程中使用类似以下内容(欢迎改进):

So the process I intend to use something like this (improvements welcome):

client: GET /some/item
myapi:  200 OK
        last-modified: time-stamp-of-v1
        etag: some-hash-relating-to-v1-of-my-item-in-this-format
        content: json or whatever
         data/for/some/item/v1... 

client: PUT /some/item
        if-match: some-hash-relating-to-v1-of-my-item-in-this-format
        content: json or whatever
         data/for/some/item/v2... 

myapi:  202 ACCEPTED,   
        content: json or whatever
         time-accepted: time-stamp-after-v1-but-before-v2
         your item will be at /some/item
         here is a URI /some/taskid to track progress

正在等待上传:

client: GET /some/item
myapi:  200 OK
        some/item ... 
        last-modified: time-stamp-of-v1
        etag: some-hash-relating-to-v1-of-my-item-in-this-format
>>>>    expires: time-stamp-after-v1-but-before-v2 <<<
>>>>    warning: 110 Response is stale    <<<<
        content: json or whatever
         data/for/some/item/v1... 

client: GET /some/task/id
myapi:  200 OK
        content: json or whatever
         time-accepted: time-stamp-after-v1-but-before-v2
         your item will be at /some/item
         status/of/upload/v2... 

任务完成后:

client: GET /some/item
myapi:  200 OKAY
        some/item/v2 ... 
        last-modified: time-stamp-of-v2
        etag: some-hash-relating-to-v2-of-my-item-in-this-format
        content: json or whatever
         data/for/some/item/v2... 

client: GET /some/task/id
myapi:  303 SEE OTHER
         look-here: /some/item

如果您是代理人，并且知道自己的内容过时，则可以在标题中输入警告:110-响应过时". 但是，在这种情况下，数据实际上还不是无效的. 我想说的是，在我收到并传递上载请求( time-stamp-after-v1-but-before-v2 或以后)之前，我可以保证它是有效的.正在与上传服务器联系).在我收到上传请求时，它还没有真正过期.我只是期望它会. (实际上，如果请求失败，则可能根本不会更新).

If you are a proxy and know know your content is stale you can put "warning: 110 - response is stale" in the header. However, in this case the data is not actually invalid yet. I would like to say that I can guarantee it is valid up until the time I received and passed on the upload request (time-stamp-after-v1-but-before-v2 or later as if I am in contact with the upload server). It hasn't really expired at the time I receive the upload request. I just expect its going to. (In fact if the request fails it might not be updated at all).

现在，默认选择是仅提供旧内容，并让客户自行追赶.这具有高延迟.如果可能的话，我想做得更好.

Now the default choice is just to serve the old content and let the client catch up on its own. This has high latency. If possible, I would like to do better.

例如，如果客户端知道文档即将到期，则它可能会更频繁地轮询，或者它可能会尝试将连接升级到Web套接字，并在我收到该文档后立即发送更新(仍算作ReST?)

For example, if the client knows the document is about to expire it could poll more often or it could try to upgrade the connection to a web-socket and get sent an update the moment I get it (would that still count as ReST?)

在另一种情况下，必须不惜一切代价避免使用过期的数据.对于这种情况，我想告诉客户端该资源暂时不可用.像我上面所说的那样，使用警告和过期字段似乎是正确的.尽管发送带有适当的重试后标头的503可能更好.

There is another case where using expired data must be avoided at all costs. For that scenario I think I want to tell the client that the resource is temporarily unavailable. Using the warning and expires fields as I have above seems correct there. Though it might be better to send a 503 with a suitable retry-after header.

所以问题是:在新版本的上传待定期间，我应该如何回复GET?

在期望使用诸如AMQP或zeroMQ之类的消息传递框架替代答案以降低延迟时，我应该指出，此API充当不愿意直接使用AMQP的客户端的AMQP网关/代理.有关使用webhook或websocket的信息仍然很有趣.

In anticipation of answers along the lines of use a messaging framework like AMQP or zeroMQ instead for low latency, I should point out this API is acting as a AMQP gateway/proxy for clients unwilling to use AMQP directly. Information on using webhooks or websockets would be still be interesting.

一些相关的有用内容是:

Some related useful content is:

• 如何正确设计一个宁静的API使缓存无效?
• https://www.w3.org/Protocols/rfc2616/rfc2616 -sec14.html
• 用于暂时不可用页面的HTTP状态代码
• http://www .albertoleal.me/posts/how-to-prevent-race-conditions-in-restful-apis.html (etag阻止种族同时上传)

• How to proper design a restful API to invalidate a cache?
• https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
• HTTP status code for temporarily unavailable pages
• http://www.albertoleal.me/posts/how-to-prevent-race-conditions-in-restful-apis.html (the etag prevents races from simultaneously uploads)

推荐答案

Tl; Dr;

正在等待上传时发送:

client: GET /some/item
myapi:  200 OK
        some/item ... 
        last-modified: time-stamp-of-v1
        etag: some-hash-relating-to-v1-of-my-item-in-this-format
        expires: time-stamp-after-v1-but-before-v2
        stale-while-revalidate: 100
        warning: 110 Response is stale
        content: json or whatever
         data/for/some/item/v1... 

乍一看，似乎使用警告是不正确的.参见 https://tools.ietf.org/html/rfc7234#section-5.5 .0

At first sight it looks like using Warning is not correct. See https://tools.ietf.org/html/rfc7234#section-5.5.0

在这种情况下，服务器充当代理(尽管不是HTTP代理). 它不会与AMQP断开连接，除非断开连接，否则代理不得发送过时的响应". 这很烦人，因为它看起来像是对的事.

In this case the server is acting as a proxy (though not an HTTP proxy). It is not disconnected from AMQP and "A proxy MUST NOT send stale responses" unless it is disconnected. This is annoying as it looked like the right thing to do here.

4.2.4.服务过时的响应

4.2.4. Serving Stale Responses

过时"响应是指具有明确到期时间的响应 信息或允许计算启发式到期时间，但 根据第4.2节中的计算不是新鲜的.

A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but is not fresh according to the calculations in Section 4.2.

如果缓存被禁止，则缓存绝对不能生成过期响应 明确的协议内指令(例如，通过无商店"或 "no-cache"缓存指令，必须重新验证" 缓存响应指令，或适用的"s-maxage"或 代理重新验证"高速缓存响应指令；参见5.2.2节.)

A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).

>除非已断开连接，否则缓存不得发送过时的响应
(即，它无法联系原始服务器或以其他方式找到
前向路径)或明确允许这样做(例如，
max-stale请求指令；请参阅第5.2.1节).

> A cache MUST NOT send stale responses unless it is disconnected
(i.e., it cannot contact the origin server or otherwise find a
forward path) or doing so is explicitly allowed (e.g., by the
max-stale request directive; see Section 5.2.1).

缓存应使用110生成警告标头字段 警告响应中的警告代码(请参阅第5.5.1节).同样地， 缓存应过时生成112条警告代码(请参阅第5.5.3节) 缓存断开时响应.

A cache SHOULD generate a Warning header field with the 110 warn-code (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD generate a 112 warn-code (see Section 5.5.3) in stale responses if the cache is disconnected.

当
转发没有Age标头字段的响应，即使 响应已经过时.缓存不需要验证响应
只是在运输过程中变得陈旧.

A cache SHOULD NOT generate a new Warning header field when
forwarding a response that does not have an Age header field, even if the response is already stale. A cache need not validate a response
that merely became stale in transit.

也

4.4.无效

4.4. Invalidation

因为不安全的请求方法([RFC7231]的4.2.1节)例如 PUT，POST或DELETE可能会更改
上的状态 原始服务器，介入缓存可以使用它们来保留其内容 最新.

Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents up to date.

>缓存必须使有效的请求URI无效(
的5.5节 [RFC7230])以及位置"和内容位置"中的URI 非错误状态代码为
时的响应标头字段(如果存在) 响应不安全的请求方法而收到的邮件.

> A cache MUST invalidate the effective Request URI (Section 5.5 of
[RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is
received in response to an unsafe request method.

但是，如果使用 stale-while-revalidate ，则需要发出警告(请参阅 https://tools.ietf.org/html/rfc5861 )

However a warning is required if stale-while-revalidate is used (see https://tools.ietf.org/html/rfc5861)

1. 重新验证时过期的Cache-Control扩展

1. The stale-while-revalidate Cache-Control Extension

在HTTP响应中存在时，过时的重新验证缓存"- 控制扩展表示缓存可以在
变陈后出现的数字，直到指定的数字为止
秒.

When present in an HTTP response, the stale-while-revalidate Cache- Control extension indicates that caches MAY serve the response in
which it appears after it becomes stale, up to the indicated number
of seconds.

stale-while-revalidate ="stale-while-revalidate""="增量秒数

stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds

如果由于存在此原因而导致缓存的响应过时了
扩展名，则缓存应尝试在静止时尝试重新验证它
提供过时的响应(即无阻碍).

If a cached response is served stale due to the presence of this
extension, the cache SHOULD attempt to revalidate it while still
serving stale responses (i.e., without blocking).

我认为目前还不清楚，所以我提交了勘误.这被拒绝(尽管在编写报告时仍按报告显示)，原因是rfc5861中的缓存控制扩展会覆盖rfc7234中的不得"(请参见上面的明确允许这样做").

I thought this was unclear so I submitted an errata. This was rejected (though at the time of writing its still showing as reported) on the grounds that the cache control extensions in rfc5861 override the MUST NOT in rfc7234 ("doing so is explicitly allowed" see above).

可以使用 expires ，但是它并不是很有帮助，因为它并不表示任何内容.

It is okay to use expires but its not very helpful as it doesn't imply anything.

5.3.过期

5.3. Expires

"Expires"标头字段提供日期/时间，之后该日期/时间
响应被认为是过时的.请参阅第4.2节，以进行进一步讨论 的新鲜度模型.

The "Expires" header field gives the date/time after which the
response is considered stale. See Section 4.2 for further discussion of the freshness model.

> Expires字段的存在并不表示原始字段
资源将在此之前，之后或之后发生变化或不再存在
时间.

> The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.

这篇关于ReST低延迟-上传未决时如何回复GET?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！