另一条路线的装饰者应该做什么路线答案

【问题标题】：What route should a decorator of another route do另一条路线的装饰者应该做什么路线
【发布时间】：2014-07-04 14:41:43
【问题描述】：

假设我有一个 RESTful API，我在其中发布到 /doSomething 以开始运行任务。这个任务启动了一个类的实例来做某事。

如果我希望能够为该任务添加任意功能，但让原始类完成大部分已经完成的工作。一般的智慧是在类上使用装饰器模式来添加我想要的功能。

我的绊脚石是我想不出一种雄辩的方式来将它添加到 RESTful API。我考虑过的选项是：

发布到/doSomething/andALittleMore。不过这会让人感到困惑，因为我可能有多个链式装饰器，这可能会导致问题。
POST 到/compose 并为原始任务和装饰器设置一堆不同的post 参数。这对于多个装饰器也会很麻烦。
POST 到/compose，并将任务和装饰器的一组选项作为 JSON 传递。这会为哪些参数用于哪些功能添加一些顺序，但 JSON 将是一团糟。
有一个接受组合命令的路由。更麻烦的是，现在我不得不担心这将使用哪种语言，可能会标记和解析该命令等。
发帖到/doALittleMore 并假装/doSomething 不是路线的一部分。这消除了 URI 的描述性。

我想不出一种方法来完成我想要做的事情，而且感觉它不会将 RESTful 精神从 API 中带走。但是 REST 和装饰器模式已经存在了很长时间。这两种设计一般是如何结合的？

【问题讨论】：

标签： rest decorator

【解决方案1】：

我建议将装饰器作为自己的端点来管理，并将它们视为任务上的集合。

GET /tasks/15/decorators - return all decorators on task 15
{
    "numDecorators": 15,
    "decorators": {
        {
            "self": "/decorators/3",
            ...
        },
        ...
    }
}
POST /tasks/15/decorators - add a decorator on task 15
PUT /tasks/15/decorators - modify order, add, delete 

GET /decorators - return all decorators
POST /decorators - create a new decorator

等等……

另一个合理的选择是将关系提取到它自己的资源中：

GET /tasks/15
GET /decorators/7
GET /task-decorators

【讨论】：