RESTful 接口中的多个实体替换
我有一个包含一些实体的服务，我想以 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作为我们可能拥有的其他实体类型的类似非静态操作的单独路径，但我不喜欢将其移到实体主路径之外.出于验证目的，我们需要能够在“空运行”模式下执行大多数操作。
查询字符串通常被认为是令人厌恶的，但我已经是过滤器的罪人了。对于验证模式，添加
?validate或?dryrun标志可以吗？有人做过类似的事情吗？有什么缺点？这是为了帮助面向用户的界面轻松实现验证。
我们不希望使用任何缓存机制，因为这是一个很少触及的微小配置服务，因此缓存优化并不是绝对必要的
I have a service with some entities that I would like to expose in a RESTful way. Due to some of the requirements I have some trouble finding a way I find good.
These are the 'normal' operations I intend to support:
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 :)
Now, the additional requirements:
We need to be able to replace the entire set of entities with a completely new set of entities (merging can occur internally as an optimization).
I thought of using
POST /rest/entityfor that, but that would remove the ability to create single entities unless I move that functionality. I've seen /rest/entity/new-style paths in other places, but it always seemed a bit odd to reuse the id path segment for that as there might or might not be a collision in IDs (not in my case, but mixing namespaces like that gives me an itch :)Are there any common practices for this type of operation? I've also considered
/rest/import/entityas a separate path for similar non-restful operations for other entity types we might have, but I don't like moving it outside of the entity home path.We need to be able to perform most operations in a "dry-run"-mode for validation purposes.
Query strings are usually considered anathema, but I'm already a sinner for the filter one. For the validation mode, would adding a
?validateor?dryrunflag be ok? Have anyone done anything similar? What are the drawbacks? This is meant as an aid for user-facing interfaces to implement validation easily.
We don't expect to have to use any caching mechanism as this is a tiny configuration service rarely touched, so optimization for caching is not strictly necessary
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这就是它的作用，不是吗？
PUT 具有替换语义。也许您可以使用 PATCH 动词来支持进行部分更新。
就我个人而言，我会将资源名称更改为“EntityList”或“EntityCollection”，但这只是因为它对我来说更清晰。
That's what this does, no?
PUT has replace semantics. Maybe you could use the PATCH verb to support doing partial updates.
Personally, I would change the resource name to "EntityList" or "EntityCollection", but that's just because it is clearer for me.