参考RESTful API中的URL

Question

以下是RESTful API的几个标准URL.

• http://api.example.com/user/123
• http://api.example.com/users

第一个检索单个用户,第二个检索用户集合(假设为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">
...

可以提供除linksJSON中的对象或XML中的标签之外的附加信息.

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

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

该集合名词被创造多为抽象的编程语言REST风格的实施,因此开发人员可以群体,更容易操纵类似资源的群体.

如果存在,查询字符串参数也标识不同的资源,因此/users/?since=2009是不同的/users/.他们都是不同的资源,虽然非常相似.

片段标识符,即使没有发送到服务器,也被认为是不同的资源,因此/users/123#bio不同/users/123.

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