在REST中,对于信息最关键的抽象即为资源。任何信息都可以被称为一个资源:一份文档或图像,一个临时的服务(例如:今天洛杉矶的天气),一个其他资源的集合,一个非虚拟化的物体(例如一个人)等等。换句话来说,任何可能成为作者超文本引用目标的概念都必须符合资源的定义。一个资源在概念上可映射为一组实体,而不是与任何特定时间点相映射的对应实体。
/customers
来标识一群顾客,同样可以使用URI /customers/{customerId}
来标识一个顾客。/customers/{customerId}/accounts
来标识。同样,在这个子资源accounts
下的一个单个的资源account
可以标识为/customers/{customerId}/accounts/{accountId}
译者注:HTTP动词(HTTP verb)指的是诸如GET, POST, DELETE, PUT这样的HTTP请求方式。有关统一接口的约束请参考本目录下的文章REST Architectural Constraints
译者注:这里的属性英文原文写的是document,字面上翻译为文档或者文件但是在这里它并不是指的传统意义上的那个文档,程序文档或代码文档。依据上下文语境,这里的document指的应该是一个资源的具体属性,它有可能是一个对象实例或者一条数据库记录,而这个属性必需以“单数”名词的形式表现在URI里面。如果有更好的翻译方法,请提交Issue或pull request
译者注:这个store究竟是个什么呢,这里肯定不能翻译成商店,翻译成存储库或贮藏处吧又不是很合适,不能合理地表述其意思。这里的store究竟是个啥呢,打个比方啊,假设说让我们设计一个类似淘宝客户端的API,用户在客户端点击将商品添加至购物车,购物车信息就可以放进这个store里,这个store是由客户端维护的,但实际的存储是在服务端的,对其的增删改查都是由客户端直接决定的,例如淘宝的购物车是同步的,你在电脑端添加了购物车在手机端也可以看到你购物车里的物品,为了实现这个购物车的同步,我们就要在服务端设置一个用来存放你当前购物车信息的数据库或存储位置,这个由客户端维护的数据库或存储库就是这里的store。在设计同步购物车API的时候,我们就要用复数名词来表示store的资源类型,就是这样。
译者注:这里的控制器资源,打个比方吧,还是那个淘宝的API,上一个store里面我们讲了一个同步购物车,现在说一下这个购物车的结算,当用户点击结账按钮的时候,调用某一个API对购物车进行结账,结账就相当于是一个控制器资源,这时这个API我们就可以设计成上面例1的形式,在URI里面加入动词checkout
,来表示结算
My-Folder
用了大写字符Content-Type
字段,以此来决定如何处理body的内容。