我一直在实现一个具有以下操作的RESTful Web服务：
列表文章：
GET /articles删除文章（应只删除选定的文章到垃圾桶）：
DELETE /articles列出垃圾桶中的文章：
GET /trash/articles我必须执行将“/垃圾/文章”中的“文章”恢复为“/文章”的操作。
这是问题。 你通常会这样做吗？ 我必须使用哪些网址？
我想出了两种做法。 首先是：
DELETE /trash/articles但感觉很奇怪，用户可以像“永久删除它，不恢复”一样阅读它。
第二种方法是
PUT /trash/articles更奇怪的是，用户会对此操作的操作感到困惑。
我是REST的新手，所以请指教您通常的做法。 我试图在谷歌搜索，但我不知道如何正确地问，所以我没有得到一些有用的东西。
I've been implementing a RESTful web service which has these operations:
List articles:
GET /articlesDelete articles (which should remove only selected articles to a trash bin):
DELETE /articlesList articles in the trash bin:
GET /trash/articlesI have to implement an operation for restoring "articles" from "/trash/articles" back to "/articles".
And here is the question. Ho do you usually do it? What url do I have to use?
I came up to the 2 ways of doing it. The first is:
DELETE /trash/articlesBut it feels strange and a user can read it like "delete it permanently, don't restore".
And the second way is
PUT /trash/articlesWhich is more odd and a user will be confused what this operation does.
I'm new to REST, so please advice how you do it normally. I tried to search in google but I don't know how to ask it right, so I didn't get something useful.
最满意答案
另一种选择是使用“查询参数”来定义一个“补充动作/动词”来涵盖你所拥有的“特殊条件”（因为HTTP动词不容易覆盖）。 这可以通过以下方式完成：
PUT /trash/articles?restore=true
这会使URI路径仍然依赖于REST指南（指的是资源，而不是对“操作”进行编码 - 比如“恢复”），并且会改变你想做的事情的“额外语义”（这是一个非常特殊的情况）到“查询参数”。 “查询参数”通常用于REST中的“过滤”资源，并非针对这种情况......但是，根据您的要求，这可能是一个合理的假设。
Another option could be to use "query params" to define a "complementary action/verb" to cover this "special condition" you have (given that this is not very easily covered by the HTTP verbs). This then could be done for example by:
PUT /trash/articles?restore=true
This would make the URI path still complaint with REST guideline (referring to a resource, and not encoding "actions" - like "restore") and would shift the "extra semantics" of what you want to do (which is a very special situation) to the "query parameter". "Query params" are very commonly used for "filtering" resources in REST, not so much for this kind of situation... but maybe this is a reasonable assumption given your requirements.
更多推荐
发布评论