我正在考虑如何构建RESTful API的端点。
问题描述
- 有配方和用户
- 用户可以保存和取消保存食谱。
- 用户可以收藏他保存的食谱，也可以取消收藏。
- 用户必须在第一次保存食谱时给它们一个名称。他可以以后再编辑这个名字。
- 应该可以轻松检索用户保存的所有食谱，以及有关哪些食谱是他最喜欢的食谱和食谱名称的信息。
问题
如何构建后端API端点?
这是4个构建它的建议。你觉得哪个更好?你还有别的建议吗?
建议1:
| 终点 | 方法 | 含义 |
|---|---|---|
users/{userId}/saved-recipes |
GET | 检索用户保存的所有食谱。响应还包含有关这些食谱的名称以及它们是否是用户最喜欢的信息。 |
recipes/{recipeId}/save |
文章 | 保存配方。 |
recipes/{recipeId}/unsave |
文章 | 恢复一个食谱。 |
recipes/{recipeId}/favorite |
文章 | 最喜欢的保存配方。 |
recipes/{recipeId}/defavorite |
文章 | Defavorite保存配方。 |
recipes/{recipeId}/edit-name |
POST | 编辑已保存菜谱的名称 |
如何构建后端API端点?
你会如何在网站上做到这一点?
你可能有一堆网页(文档)。通过抓取(GET)网页副本从服务器检索信息。信息通过建议对网页进行编辑传递给服务器。
对于在web浏览器中运行的超文本应用程序，编辑来自于提交web表单——我们倾向于使用POST处理所有事情。每一种编辑都会有自己的web表单有自己的标识符，你可以GET，表单。Action是当表单被处理时将要改变的网页的标识符。
(是的，一个网页可能是来自不同形式的几个不同编辑的目标。)
这样设计，你的"提案1";非常接近正确的想法，只是对标识符有不同的解释。
/users/1/saved-recipes
这是描述用户1保存的食谱的文档标识符。
/users/1/saved-recipes/save
/users/1/saved-recipes/unsave
/users/1/saved-recipes/favorite
/users/1/saved-recipes/defavorite
/users/1/saved-recipes/edit-name
这些是文档的标识符，包含您用来提议更改/users/1/saved-recipes的表单。在每种情况下，当您提交表单时，生成的请求使用/users/1/saved-recipes作为请求的目标uri。
如果你有一个更复杂的客户端，能够管理文档的本地编辑，那么你就不需要表单了。您可以使用GET/users/1/saved-recipes将文档复制到您的客户端，进行本地编辑，然后使用PUT/users/1/saved-recipes建议服务器将其文档副本替换为您编辑的副本。