Question

我正在编写一个应该描述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服务在abstract controller s的超媒体abstract view中提供representation和resource。

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

SearchForm - ＆gt;绑定到Query
Link - ＆gt;绑定到Query
UpdateForm - ＆gt;绑定到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词汇使用的结论：

我对此进行了很多思考，我认为这种词汇在服务器端没有普遍用途，因为资源不一定存在于服务器端，如聚合，实体等...... REST只是一种传递方式，这与域模型无关，因此我们不能使用例如资源图来生成业务逻辑类，反之亦然。 REST连接到业务逻辑的表面（就像每个传递方法一样），因此例如通过CQRS，我们可以轻松地将Command或Query实例绑定到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
            ...

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

因此，使用这种词汇来生成服务器端代码毫无意义。好的，但我们可以用它们做什么？

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

Answer 1

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

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

然而，在较窄的仅服务器上下文中，这些单词是合适的，因为REST API与服务器端应用程序的表示层（或交付或ui端口，具体取决于所选的体系结构）相关。

REST建模词汇

关于REST词汇使用的结论：

1 个答案: