Question

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

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

假设每个项目都有必填字段标题。为响应GET /items/new而返回一些默认值可能不太好。在这种情况下更好的是什么？要返回null 标题并在POST为空时返回错误？要为new资源实现类似构造函数的逻辑，请在查询字符串中询问必填字段？还有别的吗？

谢谢。

UPD。为了澄清一下，使用new并不是要将“添加”拆分为“分配”和“写内容”，因为{{1}上没有对数据存储执行任何操作}}。它旨在成为实现实体设计灵活性的一种方式：富客户端可以根据响应新内容的内容动态呈现输入字段。那有意义吗？或者合同是固定的，我们需要为这些更改修改API吗？

Answer 1

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

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

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

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

Answer 2

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

api.company.com/item

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

api.company.com/item/{id}

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

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

api.company.com/item

如果您正在使用XML，您可以为客户提供XSD，以便他们知道需要与否。如果你正在使用JSON，它可能会被记录在某个地方。

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

这是resource我经常检查以记住HTTP状态代码及其含义

创建新文档（实体），将其添加到集合中

2 个答案: