gpt4 book ai didi

用于改变实体的 RESTful URL

转载 作者:行者123 更新时间:2023-12-04 18:36:21 25 4
gpt4 key购买 nike

我前段时间开发了一个网络应用程序来许可我们的软件。这有客户、帐户、用户和许可证。许可证分配给用户并使用序列号激活。许可证是作为处理采购订单的输出而创建的,即没有任何直接发布新许可证的方法。

我目前正在阅读“RESTful Web 服务”并考虑如何使其成为 RESTful(还有 HATEOAS)。

我很清楚大部分 URL,但需要对许可证执行一些有趣的操作。许可证的基本 URL 为 /licence/{licenceID}

  • 为用户分配可用许可(由支持人员完成)
  • 释放用户的许可证(将其放回可用许可证池中)
  • 使用序列号激活许可证,生成 key 作为返回
  • 重新激活许可证
  • 将许可证更新到新的到期日期
  • 禁用许可证:仅单向,不可逆。许可证仍然存在

现在,在 REST 中,我只能使用标准方法,不能在 URL 中嵌入“分配”操作。我在想的是挑选出我想要影响的许可证部分。这给出:-

  • 列表:GET/licences/
  • 获取:GET/licences/{licenceID}
  • 分配:POST/licences/{licenceID}/assignee/{userID}
  • 发布:DELETE/licences/{licenceID}/assignee
  • 激活:POST/licences/{licenceID}/serialNumber/{serialNumber}
  • 停用:DELETE/licences/{licenceID}/serialNumber
  • 续订:POST/licences/{licenceID}/expires
  • 禁用:DELETE/licences/{licenceID}/enabled

我的问题是:-

  • 此 URL 方案是“正确”或明智的做法吗?
    • 或者我应该收集“许可分配”和“许可激活”(例如:/assignments/{licenceId}/{userId})
  • 我是否遗漏了一些基本的东西(当我读完这本书时可能会清楚)
  • 参数(userId 和 serialNumber)应该作为路径参数还是查询参数?
    • {userId} 指的是系统上的用户,因此可以作为路径参数
    • {serialNumber} 是在客户端 (Java Swing) 上根据它自己的信息生成的(没有序列号的中央数据库)。

非常感谢!

最佳答案

  • 列表:GET/licences/

很好,虽然我自己会使用 GET/licences :)

  • 获取:GET/licences/{licenceID}

看起来不错

  • 分配:POST/licences/{licenceID}/assignee/{userID}

我认为这会适得其反,除非许 cocoa 以分配给多个被许可人。相反,我建议

PATCH /licences/{licenceID}
{ assignee={userID} }

PUT /licences/{licenceID}/assignee
{userID}

选择哪个应取决于许可证的受让人更改的频率。如果经常使用,则使用后者;如果不频繁,则使用前者。

  • 发布:DELETE/licences/{licenceID}/assignee

很好。如果你使用它,那么你应该使用前面给出的两个存储选项中的第二个。如果你选择了第一个,那么是这样的:

PATCH /licences/{licenceID}
{ assignee=NULL }
  • 激活:POST/licences/{licenceID}/serialNumber/{serialNumber}
  • 停用:DELETE/licences/{licenceID}/serialNumber
  • 续订:POST/licences/{licenceID}/expires

您可以像决定受让人一样对待这三者,以使您的客户更轻松。

  • 禁用:DELETE/licences/{licenceID}/enabled

我建议:

> DELETE /licences/{licenceID}
< 201 Created
< Location: /disabled-licenses/{licenseID}

然后 URI 命名空间/licenses 将映射到您的域模型 licenses WHERE valid==true 并且/disabled-licenses 将映射到 licenses WHERE valid==false。这没有错。然后可以在 HTTP 级别(即通过 URI 路径)而不是在应用程序级别(通过检查数据库中的字段值)限制对无效许可证的访问。

我的问题是:-

  • 此 URL 方案是“正确”或明智的做法吗?
    • 或者我应该收集“许可分配”和“许可激活”(例如:/assignments/{licenceId}/{userId})

您建议的方案在进行一些改动后大部分都很好。

  • 我是否遗漏了一些基本的东西(当我读完这本书时可能会清楚)

不,不是真的。

  • 参数(userId 和 serialNumber)应该作为路径参数还是查询参数?
    • {userId} 指的是系统上的用户,因此可以作为路径参数
    • {serialNumber} 是在客户端 (Java Swing) 上根据它自己的信息生成的(没有序列号的中央数据库)。

同样,如果一个许可证只有一个用户 ID 和一个序列号,那么它们的值就是资源属性和/或子资源。如果建模为子资源,则它们属于 URI,如果是属性,则属于正文。

关于用于改变实体的 RESTful URL,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13701828/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com