指定REST GET查询的投影

red*_*edi 6 rest

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

inf*_*rno 4

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

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

请注意,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"
                            }
                        }
                    ]
                }
            }
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

其中/meta描述了每个参数的类型和标签:

获取/元/人/fname

{
    "type": "string",
    "label": "First name",
    "_links": {
        "self": {
            "href": "/meta/person/fname"
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

办公室。您与客户的第一步应该是获取整个元数据或至少其中最常用的部分。通过处理链接,客户端必须能够仅理解元描述和这种特殊的超媒体 JSON 格式。URI 结构完全无关,它应该仅使用元来理解链接是什么以及如何使用它。

不幸的是,我们目前没有关于如何描述 JSON 响应中的链接的标准。有超媒体格式,如Hydra + Json-LDHALHyperSchema等......但是据我所知。它们都还不是标准。(Hydra RDF 词汇可能是最接近的,但它肯定还没有准备好投入生产。Json-LD 已经是表示 RDF 的标准方式。)

现在,如果将如何构建/person?fields=fname,lname,addressURI 及其含义硬编码到您的客户端中,那么它就不是 REST 客户端,因为这种服务/客户端违反了REST 的统一接口/ HATEOAS约束。办公室。如今,人们。将一切都称为 REST、RESTful、API,即使他们对这个主题的了解只有 Jon Snow 多。顺便提一句。如果您不想以 REST 方式实现 Web 应用程序,也没有什么悲剧,这仅取决于您的需求。例如,如果您的应用程序没有大量用户和第三方开发人员,那么您选择哪条路径很可能并不重要。