k1e*_*ran 11 api rest api-design http
我们在REST服务器上有一些资源,结构如下:
/someResources/foo/someResources/bar/someResources/baz其中someResource是远离分布式对象的服务器表示.
我们想告诉服务器通过在网络中查看并更新服务器的缓存来"刷新"其对"分布式对象"的表示,即我们不能简单地将新值放入.
什么是干净的REST方式？
a)是否要POST到/refreshes/新的"刷新请求"？
b)是否要PUT(带空白文件)http://ip/someResources？
c)还有别的吗？
我喜欢(a)因为它会给我们一个id来识别和跟踪刷新命令,但担心我们创建了太多资源.有什么建议？
我会选择'刷新'资源方法.这有两个主要的好处
(a)与生命周期操作(复制,克隆,移动)一样,刷新的目的与底层资源的功能正交,因此应该是完全独立的
(b)它为您提供了一些检查刷新进度的方法 - 刷新资源的外部状态将为您提供"状态"或"进度"属性.
我们以这种方式实施了生命周期操作,关注点的分离是一个很大的设计.
另一种管理方法是允许服务器在一段时间内缓存它的资源表示,只在一些超时后实际检查实际状态.在此模型中,您的服务器实际上是一个中间缓存资源,应遵循HTTP缓存行为,请参阅此处以获取更多详细信息.下面我引用一个非常相关的部分,讨论客户端覆盖缓存的值.
13.1.6客户端控制的行为
虽然源服务器(以及较小程度的中间缓存,它们对响应时代的贡献)是到期信息的主要来源,但在某些情况下,客户端可能需要控制缓存的决定是否在不验证缓存的情况下返回缓存的响应.客户端使用Cache-Control标头的几个指令执行此操作.
客户的请求可以指定它愿意接受未经验证的响应的最大年龄; 指定零值会强制缓存重新验证所有响应.客户端还可以指定响应到期之前剩余的最短时间.这两个选项都增加了对缓存行为的约束,因此无法进一步放宽缓存对语义透明度的近似.
客户端也可以指定它将接受过时的响应,最多可达到一些最大的过期量.这放松了对缓存的约束,因此可能违反了源服务器对语义透明性的指定约束,但可能需要支持断开连接的操作,或者在连接不良时面临高可用性.
克里斯
| 归档时间： |
|
| 查看次数： |
4353 次 |
| 最近记录： |