REST 中的客户端服务器 API 模式（不可靠的网络用例）

发布于 2024-10-17 16:59:52 字数 580 浏览 4 评论 0原文

假设我们在不可靠的网络上发生客户端/服务器交互（数据包丢失）。客户端正在调用服务器的 RESTful api（通过 http over tcp）：

向 http://server.com/products
服务器正在创建“产品”资源的对象（将其保存到数据库等）
服务器正在返回 201 Created with a Location header of "http://server.com/products/12345"
！包含 http 响应的 TCP 数据包被丢弃，最终导致 tcp 连接重置

我看到以下问题：客户端永远不会获得新创建的资源的 ID，但服务器将创建一个资源。

问题：这是应用程序级别的行为还是框架应该处理这个问题？ Web 框架（尤其是 Rails）应该如何处理这样的情况？有关于此主题的 REST 文章/白皮书吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

[浮城] 2024-10-24 16:59:52

当服务器不响应 POST 时，客户端将收到错误。然后，客户端通常会重新发出请求，因为他们认为请求已失败。我突然想到解决这个问题的两种方法。

一是客户端可以生成某种请求标识符，例如 guid，并将其包含在请求中。如果服务器收到具有重复 GUID 的 POST 请求，则它可以拒绝该请求。

另一种方法是使用 PUT 而不是 POST 来创建。如果无法让客户端生成 URI，那么您可以要求服务器使用 GET 提供新的 URI，然后对该 URI 执行 PUT。

如果您搜索“make POST idempot”之类的内容，您可能会找到一堆关于如何执行此操作的其他建议。

回复收藏 0 原文

快乐很简单 2024-10-24 16:59:52

如果创建重复的资源（例如具有相同标题、描述等的产品）是不合理的，则可以在服务器上生成唯一标识符，可以针对创建的资源进行跟踪，以防止处理重复的请求。与 Darrel 的建议不同在客户端上生成唯一的 ID，这也将防止单独的用户创建重复的资源（您可能会或可能不希望这样做）。客户端将能够通过响应代码（在下面的示例中分别为 201 和 303）来区分“创建”响应和“重复”响应。

用于生成此类标识符的伪代码 — 在本例中，是请求的规范表示的哈希值：

func product_POST
    // the canonical representation need not contain every field in
    // the request, just those which contribute to its "identity"
    tags = join sorted request.tags
    canonical = join [request.name, request.maker, tags, request.desc]
    id = hash canonical

    if id in products
        http303 products[id]
    else
        products[id] = create_product_from request
        http201 products[id]
    end
end

此 ID 可能是也可能不是所创建资源的 URI 的一部分。就我个人而言，如果 URI 将暴露给用户，我倾向于单独跟踪它们（以额外的查找表为代价），因为哈希值往往很难看并且人类难以记住。

在许多情况下，在一段时间后让这些独特的哈希值“过期”也是有意义的。例如，如果您要开发一个转账 API，则用户在几分钟内向同一个人转账相同金额的资金可能表明客户端从未收到“成功”响应。另一方面，如果用户每月向同一个人转账一次相同金额的钱，他们可能正在支付租金。 ;-)

If it isn't reasonable for duplicate resources to be created (e.g. products with identical titles, descriptions, etc.), then unique identifiers can be generated on the server which can be tracked against created resources to prevent duplicate requests from being processed. Unlike Darrel's suggestion of generating unique IDs on the client, this would also prevent separate users from creating duplicate resources (which you may or may not find desirable). Clients will be able to distinguish between "created" responses and "duplicate" responses by their response codes (201 and 303 respectively, in my example below).

Pseudocode for generating such an identifier — in this case, a hash of a canonical representation of the request:

func product_POST
    // the canonical representation need not contain every field in
    // the request, just those which contribute to its "identity"
    tags = join sorted request.tags
    canonical = join [request.name, request.maker, tags, request.desc]
    id = hash canonical

    if id in products
        http303 products[id]
    else
        products[id] = create_product_from request
        http201 products[id]
    end
end

This ID may or may not be part of the created resources' URIs. Personally, I'd be inclined to track them separately — at the cost of an extra lookup table — if the URIs were going to be exposed to users, as hashes tend to be ugly and difficult for humans to remember.

In many cases, it also makes sense to "expire" these unique hashes after some time. For example, if you were to make a money transfer API, a user transferring the same amount of money to the same person a few minutes apart probably indicates that the client never received the "success" response. If a user transfers the same amount of money to the same person once a month, on the other hand, they're probably paying their rent. ;-)

回复收藏 0 原文