## 第一章: 使用统一的接口 已阅: Page9 ## 第13章: 可扩展性与版本控制 ## 第4章: 设计URI 对于过期的URI的处理: 前期(使用该URI的用户比较多时), 使用301重定向, 在Response header中制定Location 后期(该URI访问很少, 但还有访问): 使用410(Gone) 或者 404(Not Found), 如果使用410, 还需要制定Expires时间为未来的某个点 然后可以在response body中添加一些描述信息 ## 第5章: 如何分配链接关系类型 表: 一些常用的已注册链接关系类型 ``` self: 链接到资源的首选URI alternate: 为相同资源提供另一个版本的链接 edit: 链接到编辑资源的URI related: 链接到相关的资源上 previous和next: 链接到一系列有序资源中的上一个或者下一个 first/last: 链接到一系列资源的第一个或最后一个 自定义(url地址): { “link”: { “rel”: “http://example.org/rels/book“, “href”: “http://example.org/book/978-0452286757” } } ``` ### 如何使用链接来管理应用程序的流程? TODO ### 如何在客户端中使用链接? TODO ## 第8章: 如何针对查询设计URI ## 第9章: Web缓存 如何保持新鲜且温暖的缓存? 只有GET/HEAD/POST请求可以设置缓存, 但只有GET/HEAD才能真正的缓存数据 如何配置Nginx, 使POST/DELETE/PATCH请求会清除GET/HEAD获取数据产生的缓存呢? 即使实现了上面, 还是不能保证缓存的’新鲜’和’温暖’? 1. 服务器可能有定时任务的执行, 它会更新数据, 这些数据无法更新HTTP服务器中的缓存 2. 广泛分布的数据存储在一天里可能会周期性地进行复制, 数据的改变不会反映在全部的缓存里 3. 可能包含客户端通过非HTTP的方式更新数据, 此时缓存的数据不会同步更新 一种可能的解决方式: 实现触发器来监控数据库, 随后运行一个定时任务通过缓存发起无条件GET请求(设置Cache-Control: no-cache; Pragma: no-cache, 此时缓存会被清除掉) 要进行部分更新, 除了使用PATCH(规范不完备), 应该使用POST而不是PUT. 因为PUT是用来执行整个更新的