Question

为REST GET查询指定投影是否违反REST原则和/或这是一个好习惯吗？考虑像/person?fields=fname,lname, address这样的api，这可能是因为人是一个大模型而且对于我目前的要求我只需要给定字段的值（比如我正在创建一个UI网格）

Answer 1

如果当前的资源不支持您想要的资源，那么定义新资源是完全可以的。这正是REST的工作方式。

因此，在您的情况下，/person?fields=fname,lname, address URI定义完全有效。

请注意，URI结构无关紧要，您必须提供指向描述URI模板和变量的客户端的链接。所以你应该返回类似这样的链接（虚构的超媒体JSON格式）：

{
    "_links": {
        "/meta/person/list": {
            "href": "/person{?fields}",
            "vars": {
                "fields": {
                    "required": false,
                    "composition": [
                        "fname": {
                            "meta": "/meta/person/fname"
                        },
                        "lname": {
                            "meta": "/meta/person/lname"
                        },
                        "address": {
                            "meta": "/meta/person/address",
                            "alternatives": {
                                "href": "/locations",
                                "meta": "/meta/locations"
                            }
                        }
                    ]
                }
            }
        }
    }
}

/meta描述每个参数的类型和标签：

GET / meta / person / fname

{
    "type": "string",
    "label": "First name",
    "_links": {
        "self": {
            "href": "/meta/person/fname"
        }
    }
}

OFC。你与客户的第一步应该是获得整个元或至少是最常用的部分。通过处理链接，客户端必须能够理解元描述和这种特殊的超媒体JSON格式。 URI结构完全不相关，它应该只使用meta来理解链接是什么，以及如何使用它。

不幸的是，我们目前没有关于如何描述JSON响应中的链接的标准。有超媒体格式，如Hydra + Json-LD，HAL，HyperSchema等......但是afaik。它们都不是标准。（也许Hydra RDF词汇最接近成为一个，但它肯定还没有生产就绪.Json-LD已经是表示RDF的标准方式。）

现在，如果它被硬编码到您的客户端如何构建/person?fields=fname,lname,address URI及其含义，那么它不是REST客户端，因为这种服务/客户端违反了uniform interface / { {3}} REST的约束。 OFC。现在人们。将所有内容称为REST，RESTful，API，即使他们只知道Jon Snow关于该主题的内容。顺便说一句。如果您不想以REST方式实现Web应用程序，那就没有悲剧，它只取决于您的要求。例如，如果您的应用程序不会有很多用户和第三方开发人员，那么您选择的路径很可能无关紧要。

指定REST GET查询的投影

1 个答案: