Question

我正努力提供适当的REST URL，以将一种资源转换为另一种资源。 API方法不执行任何CRUD操作，而是将一种资源转换/转换为另一种类型的资源。

我有2个资源Workunit和Document。我对这两种资源进行了3次操作

1>将Workunit转换为Document
2>将Workunit同步到Document（逻辑与变换不同）
3>将Document转换为Workunit

我有以下网址

[POST]  api/v1/workunits/transform
[POST]  api/v1/workunits/sync
[POST]  api/v1/documents/transform

问题在于操作是REST URL的一部分

有什么建议吗？

Answer 1

问题在于操作是REST URL的一部分

这不是问题-客户端不依赖URL的语义，因此您可以使用任何喜欢的拼写； api/v1/4dc233fa-c77c-49d7-b7d6-296ffeb89612非常令人满意。

这类似于将动词用作变量名-它可能不符合您的本地编码标准，但是编译器不在乎。 URL和使用它的通用组件也是如此。

选择一个好的标识符就像选择一个好的名字。它需要对事物是什么有一个清晰的了解。在URI / URL的情况下，被标识的事物是一种资源，也就是说由文档描述的事物。 GET / POST / PUT / DELETE等都是我们对基础文档做一些有趣的请求。

因此，通常的模式可能是将transform消息发布到工作单元资源，或者将transform消息发布到Document资源，或者将同步消息发布到工作单元资源。 / p>

嗯，最后一个听起来倒是；如果工作单位保持不变，并且文档已通过同步更改，则您可能会将同步消息发送到文档资源。

因此，如果我拥有/ api / v1 / documents / 1，并且需要对其进行同步，那么我通常会使用POST /api/v1/documents/1，并使用消息正文中描述的同步语义（在Web上，通常是同步消息的application/x-www-form-urlencoded表示形式。

但也很可能是一条消息，“我将{/ 1}与workitem / 2同步文档/ 1”同步到同步器的待办事项列表。

我们只是putting documents politely into the server's in-tray，所以它可以做有用的工作。托盘中可以有您想要的任何标签。

Answer 2

在特定情况下很好。

尽管如此，如果我说对了，最好创建两个不同的控制器。

由您决定，但可以考虑稍微改变一下结构：

将Transformation和Sync的逻辑分为两个不同的控制器，因此可以避免出现URL问题。

TransformationController

[Route("api/v1/transformation-controller/")]
TransformationController : ControllerBase
{
     [HttpPost("workunits")]
     public Task<Response> TransformWorkunits()
     {
          //logic
     }

     [HttpPost("documents")]
     public Task<Response> TransformDocuments()
     {
          //logic
     }
}

SynchronizationController

[Route("api/v1/synchronization-controller/")]
TransformationController : ControllerBase
{
     [HttpPost("workunits")]
     public Task<Response> SyncWorkunits()
     {
          //logic
     }
}

因此URL将是：

[POST] api/v1/transformation-controller/workunits
[POST] api/v1/synchronization-controller/workunits
[POST] api/v1/transformation-controller/documents

因此，这是避免动词并符合REST规则的一种方法。

如果有更多的对象要来回变换/同步，那么您将不得不改进这种方法。

用于将一种资源转换为另一种资源的REST URL

2 个答案: