4

假设我们有一个集合/items/，我们希望允许客户向这个集合添加新项目。受 Rails 的启发，我得出以下结论：我们只需添加资源/items/new，想要添加项目的人首先发布问题GET /items/new，接收空实体（可能设置了一些默认值），然后填充所需的字段和问题POST /items/。

  • 这种方法对真正的 REST API 有用吗？有什么可以改进/返工的？
  • 如果突然这种方法很好（如果不是，无论如何）：

    假设每个项目都有必填字段Title。返回一些默认值以响应GET /items/new. 在这种情况下什么更好？返回null Title并在 POST 为空时返回错误？为new资源实现类似构造函数的逻辑，例如在查询字符串中询问必填字段？还有什么？

谢谢你。

UPD。澄清一下，使用new不是将“添加”拆分为“分配”和“写入内容”，因为没有对数据存储执行任何操作GET /items/new。这是一种在实体设计中实现灵活性的方法：富客户端可以根据响应新出现的内容动态呈现输入字段。那有意义吗？或者合同要修复，我们需要为这样的变化对 API 进行版本控制？

4

2 回答 2

3

为什么首先返回一个空项目？我只是让客户端将一个新项目（包括其所有属性）发布到 /items/new 。至少这是我记得在 Rails 中完成的方式；）

在任何情况下，空项目的额外返回都没有用，增加了额外的网络往返，并可能通过将“添加”操作拆分为“分配”和“写入内容”来破坏 REST 方法。

如果您想进行任何唯一性检查、UID 生成等，可以通过一个“添加完整项目”操作来完成（或更好）。

更新：混乱可能来自这样一个事实，即 rails 控制器既充当 REST API 又充当 Web UI 的控制器。这意味着某些操作在 API 中是有用的（由某些应用程序/代码使用），而有些操作是必需的，因为表示层（由人类使用）需要它可以调用的东西。我真的不认为“新”操作在 API 中有用，但用户确实需要一些他可以调用的东西来获得一个空表单。

于 2013-03-11T16:42:15.130 回答
2

通常当我创建一个 REST API 时，我使用实体名称的单数形式，所以它是

api.company.com/item

从那里如果客户想要一个特定的项目，他们会做一个 HTTP GET

api.company.com/item/{id}

通常你不希望动词出现在 URL 中。所以“项目/新”是糟糕的设计。标准的 HTTP 方法应该足够了（GET、POST、PUT、DELETE）

因此，对于您的情况，我建议不要执行“item/new”，而是让客户端执行 HTTP POST 到

api.company.com/item

如果你在做 XML，你给客户一个 XSD，这样他们就知道需要什么。如果您使用的是 JSON，它可能会记录在某处。

至于强制执行所需的“标题”字段，我将对发布到您的资源的所有新实体进行验证。我假设您有一个已发布数据映射到的域模型。您可以只进行验证并返回状态为 400 的 HTTP 响应，或者如果您的 API 具有自定义错误响应，请使用它。

这是我经常查看的资源，以记住 HTTP 状态代码及其含义

于 2013-03-11T16:48:30.083 回答