ASP.NET Web API设计 [（美）布洛克著]
包含内容: PDF
作者QQ549710689
下载电子书
仅仅是一个资源的唯一标识符。前面给出的URI例子中最后一个例子是本书的URN,其他都是URL。这个URN只标识了本书,但是不包含关于如何获取该书的信息。在实际应用中,你看到的大多数URI都是URL,因此URI和URL常常同义替换使用。是否使用查询宇符串?有一个经常被讨论的问题:要不要在URI中使用查询字待串?这个问题的回答和存机制有关。有些存会自动忽略任何带有查询字串的URI。也就是说,所有带查询字待串的URI请求都会转到源服务器( origin server))进行处理,而这会对系纯的扩展产生重要影响。于是,有些人倾向于不使用查询字待串,而把这邮分信息放在URI路径中。谷歌推荐的做法(参见htps/developersgoogle.com/speed/docs/insights/Leveragerowsercaching#Leverageproxy Caching)是:对静态黄源不要使用查询宇待串,以便存1.1.3酷URI酷URI(hup/ww,w3.orgy/ TR/cooluris/#cooluris)是简单易记而且不变的URI(例如htp∥www.example.com/people/alice)。如果URI发生改变,那么链接到这个URI的现有系统将不能继续工作,所以有些URI需要保持不变。如果你希望客户端保存指向你的资源的书签,那么就应该考虑使用酷URI。如果你有一些网页,常常被其他网站添加链接,或者被用户存储在浏览器收藏夹里,那么,酷URI会非常好用。但是,不是所有情况下都要用到酷UR。你在这本书中将会看到,不必用很多酷URI,API设计也可以做得很好。1.1.4表示示是资源在某个时刻状态的快照。当HTP客户端请求一个资源时,返回的是这个资源的表示,而不是资源本身。从一个请求到下一个请求发生时,资源的状态可能会发生很大的变化,因而返回的表示也会大不相同。例如,假设有一个提供开发者文章的API,通过访问URIhttp;/devarticles.com/articles/top得到排名第一的文章,这个API返回的不是指向该URI内容的链接,而是到那篇文章的重定向信息。随着时间的推移,文章排名发生变化,(重定向返回的)资源的表示也会随之改变。在这个例子里,资源并不是那篇文章,而是服务器上运行的逻辑,这个逻辑从数据库中获取排名第一的文章,从而返回重定向信息。需要注意的是,一个资源可以有一个或多个表示,详见1.2.8节。