我想开发一个REST风格的API使用超文本作为应用程序状态主体的引擎。超媒体Restful API使用链接标题和范围
我已经决定使用链接标题(RFC5988)进行所有'状态转换',将链接放置在那里似乎很自然,并且不会在实现上使我的响应类型特定(例如XML/json/etc都只是工作)。
我现在在挣扎的是一组资源的分页。在过去,我使用Range头来控制它,所以客户端可以发送“Range:MyObjects = 0-20”并返回前20个。看起来自然要包含一个“下一个”关系来表示接下来的20个项目(但可能不是),但我不确定如何去做。
许多例子都将范围信息作为URI的一部分。例如,这将是
Link: <http://test.com/myitems?start=20&end=40>;rel="next"
使用范围头我会做一些像下面?
Link: <http://test.com/myitems;rel="next";range="myitems=20-40"
的这里关注的是,该链接的感觉非标准。客户必须检查范围标题以获取下一个项目。
另一件事是,我是否会将这一切都作为一些带外信息?不要显示下一个/前一个范围(这种类型取决于客户端在做什么),并期望客户端在需要时只需要序列化它所需的内容?我可以使用“接受范围,”链接提示在初始链接到集合,让客户知道它的“分页”
例如像
OPTIONS http://test.com
-> Link:"<http://test.com/myitems";rel="http://test.com/rels/businessconcept";accepts-ranges="myitem""
然后客户会去,哦,它接受范围,我只会拉下第一个X,然后根据需要去下一个范围(这种感觉像是隐式状态)。
我似乎可以弄清楚HATEOAS在这里最好的精神是什么。
我想问题是,它提供它在rel docs可以接受?它可能是,但如果我使用这种分页方式'next'/'prev'永远不会被使用。我已经使用http://tools.ietf.org/html/draft-nottingham-link-hint-00并可以添加范围,但当然客户必须从中建立一个请求。 (根据服务器提供的信息) 不确定哪一个是最好的HATEOAS,或者只是将范围数据包括为查询参数。我真的很喜欢使用范围/内容范围的概念,因为它感觉就像我在处理更多懒惰的评估流。 –