RESTAPI设计-通过按ID加载创建资源

我的REST服务需要支持加载/重新加载资源的能力，而不是直接创建资源

迄今为止：

GET /books
GET /books/12345
DELETE /books/12345

一本书看起来像：

{"id": 12345, "title": "three little bears", "author": ...}

目前还不清楚

Request:  PUT /books/12345
Response: HTTP 204 No Content

或

是“加载”/“重新加载”书籍的更好方法

详细信息：“加载”/“重新加载”将查询数据库以按id检索图书，并将结果放入持久缓存中。缓存是GET请求的参考对象。书的属性可以在数据库中更改，这意味着“加载”/“重新加载”不是幂等的。只有管理员才能使用加载/重新加载和删除操作

我认为正确的方法是POST，因为PUT应该是幂等的。然而，一篇帖子似乎很奇怪，因为针对id=12345的/book的多篇帖子只会导致创建一个资源（尽管多次重新创建）

我已经考虑过下面的附加选项，但它们似乎更令人震惊：

* POST /books/12345/load
* POST /books/load, with payload {"id": 12345}
* POST /load/book, with payload {"id": 12345}

想法

更复杂的是，我还想提供一个异步加载/重新加载操作，但我不想创建一个用户可以跟踪的操作/作业资源，我只想要一个fire and forget

示例：对于图书12345，异步加载/重新加载到缓存中。我只需要服务以接受的HTTP 202响应，这就足够了。无需询问加载/重新加载的进度

---

TL；博士：我正在建立一个REST服务来存放书籍。加载/重新加载和删除操作只能由管理员执行，而GET对所有人都是开放的。加载/重新加载操作应该从数据库中加载/重新加载记录。

如果我没有弄错，您有一个

• 起源
• 数据库
• 客户

如果客户机

GET

s a

book

，则从数据库获取资源。 数据库不知道这本

书

是否同时被修改，它提供的是过时的版本？因此，您希望客户端

发布

或

放置

资源，以强制数据库再次从源站获取条目

想想这个：

源缓存其内容，数据库缓存其内容，客户端也缓存

如果用户点击F5，客户端将重新加载资源，对吗？ 这是一种良好的行为吗？不 客户端检查资源是否过时，并且仅在必要时获取资源，这是否更好？对 这可以通过发送一个

HTTP-HEAD

请求服务器上一次修改的日期来实现，如果客户端检索日期较旧，他需要再次获取，否则他可以从缓存中提供服务

这同样适用于数据库/原始星座。数据库需要验证其内容是否仍然是请求的最新内容，并为其提供服务或从源站获取它，更新缓存并为新条目提供服务

---

因此，客户机仍然会

获取资源，如果他不想以任何方式更改资源，那么什么才是准确的。
我认为您不应该在资源路径中使用操作名称（比如
/books/12345/reload
，…），因为它不是真正的RESTful。也就是说，我同意你的观点，方法
POST
是正确的使用方法

在我看来，您应该为资源路径
/books/12345
使用方法
POST
。它将对应于操作加载/重新加载，并且可以是异步的，即返回状态代码
202è。如果你已经有了一个方法< /代码> POST，你应该考虑使用这个博客帖子中描述的策略：
希望它能帮助你，
蒂埃里
我已经更新了描述，使其更加清晰。简言之：我正在构建一个REST服务，用于缓存书籍。加载/重新加载和删除操作只能由管理员执行，而GET对所有人都是开放的。加载/重新加载操作应从源数据库加载/重新加载记录，并将其放入缓存。注：同意HEAD将是一个有用的补充。
* POST /books/12345/load
* POST /books/load, with payload {"id": 12345}
* POST /load/book, with payload {"id": 12345}