Question

以下是RESTful API的几个标准网址。

第一个检索单个用户，第二个检索用户集合（假设为20）。

引用这些网址的“REST”字词是什么？将它们称为资源是否正确？如果第一个是资源，第二个应该是资源集合还是应该只是类型集合的资源？

Answer 1

RESTful应用程序上的每个URI都是一个资源，这个描述就足够了。

链接到同一类型的多个资源的资源可能被称为集合，但没有正式名称。每个资源，无论是否为集合，都可以有链接。

资源之间的链接是RESTful系统的超媒体部分。最近，出现了一个新术语：HATEOAS，超媒体作为应用程序状态的引擎。

将复合命名为复数是一种常见的良好做法，因此您的/users/示例似乎是正确的。用户123是用户集合的子项，因此最好将其置于/users/123下复数。

RESTful，HATEOAS应用程序将响应/users/上指向各个资源的链接列表。类似的东西：

{
    "links": [
        {
            "href" : "/users/123/"
            "title" : "Alexandre Gaigalas"
        },
        {
            "href" : "/users/125/"
            "title" : "John Doe"
        },
    ]
}

或者用XML：

<link href="/users/123" title="Alexandre Gaigalas">
...

除了JSON中的links对象或XML中的标记之外，还可以提供其他信息。

这些链接可以稳定资源之间的RESTful超媒体关系。我给出的样本大多是集合和个体之间的分层，但可以声明其他类型的链接：

<link href="/users/123/picture.jpg" title="Alexandre Gaigalas avatar" rel="picture">

集合术语的创建主要是为了在编程语言中抽象RESTful实现，因此开发人员可以更轻松地对类似资源组进行分组和操作。

如果存在，查询字符串参数也会标识不同的资源，因此/users/?since=2009与/users/不同。它们都是不同的资源，尽管它们非常相似。

片段标识符，即使未发送到服务器，也被视为不同的资源，因此/users/123#bio与/users/123不同。

如果可能，更有意义的分页更好。页面编号很难处理，因为它们会发生很大变化。如果存在经常更新的集合（例如，StackOverflow问题列表），则页面1经常更改，并且用户可能会丢失从第1页到第2页的更改项目。大多数集合可以按日期或按字母顺序分页。增量页码不是错误的，但有更好的机制。

参考RESTful API中的URL

1 个答案: