在RESTful中设计操作--什么时候RESTful也是RESTful？

Question

我正在为我们正在进行的项目设计REST。也就是说，我正在编写稍后将实施的规范。

我很难思考名词/资源，而不是动作/动词。在不涉及太多项目细节的情况下，我们正在围绕SVN编写一个API。例如，采取向SVN服务器提交更改的操作。在我们的项目中，我们有多个提交操作的定义/版本：

files)

• ...

• 只需提交所有已更改的文件
• 提交一个已更改文件列表(一个子集)，而不是整个已更改的

文件。

(1)您将如何设计URL？第一个问题是，如何将提交动作描述为名词/资源而不是动词？

有人会说：

POST/PUT http://server.com/api/revision/commit

是帖子还是推荐信？我并没有真正创建提交资源，所以它不是一个帖子。但是，我并没有真正改变提交资源，所以它不是PUT。实际上，这不是资源，而是一种行动。一旦该操作被执行，它就消失了，没有资源可以创建、更改或保存以供以后参考。

也就是说，它必须是一个资源，所以URL可能应该是这样的

POST http://server.com/api/revision/commitment

这也是一个帖子，因为我们正在创造一个承诺。我们没有改变任何东西，所以不放。还请注意，我将“承诺”改为“承诺”，以反映我们正在处理的资源问题。

这有道理吗？对我来说没有，它让我发疯。我想要执行一个操作，而不是创建一个类似于该操作的资源。但不管怎样。

尽管如此，更进一步说，我刚刚创建了一个承诺资源。因此，从逻辑上讲，我应该能够在以后检索到它：

GET http://server.com/api/revision/commitment/:id

但是没有承诺资源！为了成为RESTful，我被迫做了一个。头爆

那么，如何在REST中真正指定资源上的操作呢？我指的不是创建资源的操作类型(创建用户，.)，而是操作资源或对资源进行操作的操作类型(提交修订，.)。

(2)其次，在第二个定义(见上文)的情况下，我们如何指定已更改文件的子集？在主体中通过参数或某些结构(例如，JSON数组)？哪一种更好？有什么一般规则吗？

谢谢大家！

Answer 1

有时，在URL设计中备份比继续进行更容易。在我看来，你所谓的“承诺”实际上是一个修正本身。svn commit的基本意思是，“请接受我目前选择的修订版中的这些差异，作为一个新的(子)版本”。因此，您需要识别当前选择的修订(为了保持无状态)，然后以有意义的方式追加：

POST http://server.com/api/revisions/16/children/

也就是说，发布一个封装了与版本16不同之处的实体，然后服务器可以使用201 Created，加上Location: /api/revisions/23/ (或/api/revisions/16/children/1，重定向到前者)进行响应。

然后，您不仅提供了创建新的修订，而且很可能还添加了一个给定版本的直接子版本的有用列表。

Answer 2

停止行动中的思考；

首先，将SVN设置为基于文件的，而不是基于数据库的，这将有助于思考。

如果您仔细想想，您的存储库上只有3个restfull (实际上可能是4个)操作: svn + svn提交将一个新文件置于版本控制之下。这将转换为要添加和提交文件的文件夹上的PUT。实际上，由于已知文件的"id“，您实际上可以直接放在文件的URL上:svnroot:/project/文件夹/file.c

您希望提交一个更改，这将转换为资源上的一个帖子(不是文件夹，而是该文件夹中的实际存在文件)。POST svnroot:/project/文件夹/file.c

如果您想要删除一个文件，它显然是一个删除。

如果您想知道某个文件的修订号有什么使用状态。

开始考虑实际发生的事情，而不是动词的名称(co、ci、add、update等)，发生的情况是在存储库中“创建”文件，即PUT，即PUT，即POST或DELETE /removed，或者询问状态即状态。

如果您检索该文件，这显然是一个GET。

因此，以上所述实际上是一种现有资源。现在您可以开始发明更多的特性，给文件一个大小和一个作者或最后一个提交者或提交消息！现在您需要处理URL，因为它不存在真正的资源。有人称之为虚拟资源。

只需将"/authors“等添加到资源URL的末尾，并使用POST添加一个作者并读取作者。(就味觉而言，你也可以使用PUT，按照REST的模式，也许会更干净)