1

我有一项服务，其中包含一些我想以 RESTful 方式公开的实体。由于某些要求，我很难找到一种我觉得不错的方法。

这些是我打算支持的“正常”操作：

GET /rest/entity[?filter=<query>] # Return (matching) entities. The filter is optional and just a convenience for us CLI curl-users :)

GET /rest/entity/<id> # Return specific entity

POST /rest/entity # Creates one or more new entities

PUT /rest/entity/<id> # Updates specific entity

PUT /rest/entity # Updates many entities (json-dict or multipart. Haven't decided yet)

DELETE /rest/entity/<id> # Deletes specific entity

DELETE /rest/entity # Deletes all entities (dangerous but very useful to us :)

现在，附加要求：

  • 我们需要能够用一组全新的实体替换整个实体集（合并可以在内部作为优化发生）。

    我想过使用POST /rest/entity它，但除非我移动该功能，否则这将删除创建单个实体的能力。我已经在其他地方看到过 /rest/entity/new-style 路径，但是为此重用 id 路径段似乎总是有点奇怪，因为可能会或可能不会在 ID 中发生冲突（在我的情况下不是，但是像这样混合命名空间让我很痒:)

    这种操作有什么常见的做法吗？对于我们可能拥有的其他实体类型，我还考虑/rest/import/entity将其作为类似的非静态操作的单独路径，但我不喜欢将其移到实体主路径之外。

  • 出于验证目的，我们需要能够以“试运行”模式执行大多数操作。

    查询字符串通常被认为是诅咒，但我已经是过滤器的罪人。对于验证模式，添加?validateor?dryrun标志可以吗？有没有人做过类似的事情？有什么缺点？这是为了帮助面向用户的界面轻松实现验证。

我们不希望使用任何缓存机制，因为这是一个很少涉及的小型配置服务，因此缓存优化并不是绝对必要的

4

1 回答 1

2

我们需要能够用一组全新的实体全新的一组实体替换整组实体

这就是它的作用，不是吗？

PUT /rest/entity

PUT 具有替换语义。也许您可以使用 PATCH 动词来支持进行部分更新。

就个人而言，我会将资源名称更改为“EntityList”或“EntityCollection”，但这只是因为它对我来说更清晰。

于 2010-10-04T13:34:47.143 回答