REST 建模词汇答案

【问题标题】：REST modeling vocabREST 建模词汇
【发布时间】：2014-06-30 16:10:15
【问题描述】：

我正在研究一个应该描述 REST 应用程序的词汇，但我找不到合适的词。

resource
    operations
        command/query extends operation
            name
            parameters
                parameter
                    name
                    type
                    ...
    properties
        property
            name
            type
            ...
representation
    controllers
        controller
            operation -> resource.operation
            inputs
            ...
    *s
        *
            property -> resource.property
            type
            transformation (e.g., datetime to iso8601)

我正在寻找的是*。根据一篇关于 REST 的文章，REST 服务在resources 的超媒体representations 中提供abstract controllers 和abstract views。

我不确定，我应该将* 称为view，还是有更好的词？通过控制器这个类比完美地工作，我可以有不同类型的控制器：

SearchForm -> 绑定到Query
Link -> 绑定到Query
UpdateForm -> 绑定到Command

等等……

请注意，这不是实现，这是可以描述每个 REST 服务的元数据的词汇。例如通过 HAL+JSON 响应可以这样描述：

{ //representation
    "_links": { // controllers
        "self": { "href": "/product/987" }, // a link
        "upsell": [
            { "href": "/product/452", "title": "Flower pot" }, // a link
            { "href": "/product/832", "title": "Hover donkey" } // a link
        ]
    },
    // *s
    "name": "A product", // a *
    "weight": 400 // a *
}

关于REST vocabs使用的总结：

我想了很多，我认为这种词汇在服务器端没有一般用途，因为资源不一定存在于服务器端作为聚合，实体等......REST只是一种交付方式，这与领域模型无关，因此我们不能使用例如资源图来生成业务逻辑类，反之亦然。 REST 连接到业务逻辑的表面（就像每个交付方法一样），因此例如通过 CQRS，我们可以轻松地将命令或查询实例化绑定到 REST 操作，但我们不能将聚合绑定到 REST 资源。 REST 资源只能是发送到业务逻辑（或从业务逻辑接收）的 DTO 的一部分...

resource -> cannot be bound to any business logic class, any aggregate, etc...
    operations
        command/query -> can be bound to CQRS Command/Query (DTO) classes
            name
            parameters -> can be bound to CQRS Command+Query class properties
                parameter
                    name
                    type
                    ...
    properties -> cannot be bound to properties of business logic classes, aggregates
        property
            name
            type
            ...

我看到有人混淆了这两个术语，并尝试使用 REST 资源来描述他们的应用程序的业务逻辑。对于非常简单的应用程序，这可能会起作用，但对于更复杂的应用程序，这会失败，因为从仅描述应用程序交付方法的配置生成复杂的应用程序要困难得多......

所以使用这种词汇来生成服务器端代码是没有意义的。好的，但我们可以用它们做什么？

我们可以在 REST 中使用它们将元数据添加到超媒体响应中。例如，我们可以在模板中使用它们或在构建器中添加它们。此元数据对于生成通用 REST 浏览器和特定于应用程序的 REST 客户端非常有用。例如，myApp:operation 可以绑定到 rest:controller 实例。通过了解rest:controller 类，REST 客户端可以显示链接或表单，并且通过了解myApp:operation，REST 客户端可以显示特定于该操作的链接。例如，通过webshop:addToCart 操作，它可以将购物车图标显示为提交按钮等...使用带有 RDF 响应的语义 REST API（例如 JSON-LD），是在超媒体中使用 vendor specific MIME types 的更好选择回复。

【问题讨论】：

标签： rest

【解决方案1】：

我决定使用控制器并查看单词。

我认为这些词由完整的应用程序上下文保留，因为 REST 超媒体只返回抽象控制器和抽象视图，而真正的控制器和视图类在客户端。

但是，在狭义的、仅限服务器的上下文中，这些词是合适的，因为 REST API 与服务器端应用程序的表示层（或交付或 ui 端口，具体取决于所选架构）相关。

【讨论】：