代码之家 › 专栏 › 技术社区 › LiorH

REST中版本控制操作的建模

modeling rest version-control

LiorH · 技术社区 · 16 年前

我们最近在系统中添加了版本控制功能,我们很难用RESTful方式对这些功能进行建模。

当系统配置为“版本控制”模式时,在对实体进行修改之前,必须先将其签出(为该用户创建一个私有副本)。修改本地副本后,用户可以签入以提交更改,或撤消签出以放弃更改。

所以,假设我们有一个资源(名为my resource)

  http://my-system/my-resources/{id}

以运营为导向

登记入住: http://my-system/my-resources/ {id}/登记

退房: 在上发布 http://my-system/my-resources/

获取版本: 获取 http://my-system/my-resources/ {id}/versions/{version id}

撤消签出 :开机 http://my-system/my-resources/ {id}/撤消签出
登记入住: 在上发布 http://my-system/my-resources/

退房: 在上发布 http://my-system/my-resources/ {id}/签出

获取版本: 获取 http://my-system/my-resources/ {id}/versions/{version id}

撤消签出 :删除 http://my-system/my-resources/ {id}/签出

你怎么认为? 您对如何对这些操作进行建模有什么建议吗?

3 回复 | 直到 16 年前

rcoder 16 年前

这看起来很简单 RCS -样式版本控制模型。假设与您建议的基本资源URL结构相同,我将在RESTful API中将其建模如下:

获取 http://my-system/my-resources/ X-checkout-status: unlocked

http://my-system/my-resources/

创建状态a Location:

获取 http://my-system/my-resources/ {id}/versions/{version}=>获取资源的签出版本

放 http://my-system/my-resources/ {id}/versions/{version}=>保存对已签出资源的更改

发布 http://my-system/my-resources/ {id}/versions/{version}=>将更改提交到已签出的资源,并将其保存到流程中的主资源(可能需要 X-checkout状态:解锁

http://my-system/my-resources/

删除 http://my-system/my-resources/ 锁定文件;应该需要管理权限(但对于清理过时的锁很有用)

X-checkout-status 以指示文件当前是否被锁定以及各种版本控制操作的成功或失败。

John Millikin 16 年前

您刚才描述了两个RPC API。如果您想要一个RESTful API,请尝试以下操作:

GET {resource url}
200 OK
Location: {resource url}
<resource>
    <!-- Rest of your resource goes here -->
    <operation id="check-out" href="{check-out url}" method="post">
</resource>

使用资源表示中的URL和方法,您可以签出资源以创建工作副本:

POST {check-out url}
200 OK
Location: {working copy url}
<working-copy>
    <!-- Info about the working copy goes here -->
    <operation id="check-in" href="{check-in url}" method="post">
    <operation id="discard" href="{undo check-out url}" method="post">
    <!-- Additional operations, as needed, to modify the working copy -->
</working-copy>

使用工作副本中定义的操作,在完成后将其签回:

POST {check-in url}
200 OK
Location: {resource url}
<resource>
    <!-- Modified resource data goes here -->
    <operation id="check-out" href="{check-out url}" method="post">
</resource>

或丢弃它:

POST {undo check-out url}
200 OK
Location: {resource url}
<resource>
    <!-- Original resource data goes here -->
    <operation id="check-out" href="{check-out url}" method="post">
</resource>

现在,您的每个资源都是自描述的,并且有自己的URL来唯一标识它们。

Pete Kirkham 16 年前

不是REST(尽管Fielding是委员会成员),但 WEBDAV 是通过HTTP进行版本控制的标准方式。

另一个Apache项目, Sling ,似乎包含存储库上的REST API(尽管我在任何地方都看不到HTTP API的完整描述,只有很小的示例)

第三个值得一看的地方是 Atom Publishing Protocol