REST 结构，其中“可发现性”不可能
我很难弄清楚如何最好地定义 REST/HATEOAS 服务的任何选项，由于可用资源选项的数量巨大，不可能详尽地列出可用的资源选项。
特别是，系统的一部分将是大型文本语料库中索引单词使用统计的资源 - 类似于 GET http ://mysite.org/word_statistics/foobar 返回有关 foobar 的信息以及使用 foobar 的文档的 URI。
但是，我无法提供任何合理的方式让应用程序可以发现实际的 http://mysite.org/word_statistics/ foobar 链接 - 规范的方法似乎是提供类似 http://mysite.org/word_statistics 将返回单个 URI 的列表，但在我的例子中，该列表将大约为 1 GB，因此不太实用。因此，我需要为请求应用程序提供类似 http://mysite.org/word_statistics/{your_query_here但似乎没有 RESTful 方法可以做到这一点。
这应该如何正确完成？
I have trouble figuring out any option on how to best define a REST/HATEOAS service where exhaustively listing available resource options is not a possibility due to the huge number of them.
In particular, a part of the system would be resources for indexed word usage statistics in a large corpus of text - something like GET http://mysite.org/word_statistics/foobar that returns information on foobar and URI's to documents where foobar is used.
However, I can't provide any reasonable way where the app might discover the actual http://mysite.org/word_statistics/foobar link - the canonical approach seems to be to provide a resource like http://mysite.org/word_statistics that would return a list of the individual URI's, but in my case that list would be around a gigabyte, so not reasonably practical. So I'd need to give the requesting app something like http://mysite.org/word_statistics/{your_query_here}, but there seems to be no RESTful way to do that.
How should this be done properly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我只会遵循许多地方使用的经典搜索模式。
http://example.org/word_statistics -- 这将返回所有内容、单词和链接，但您不想返回所有内容，因此您不会返回相应的错误代码，并且可能包含您支持的查询选项的描述。或者您可以返回所有内容，但以页为单位（一次 10、100、1000 个单词...）。
http://example.org/word_statistics/{word} -- 给定单词的统计信息.
http://example.org/word_statistics?like=word -- 这会返回与“类似”单词的单词列表，这可以处理拼写错误和声音相似等问题。
http://example.org/word_statistics?from_word=word1&to_word=word2< /a> -- 返回一个单词列表，按字母顺序从 from_word 开始，到 to_word，但与原始列表具有相同的限制和分页约束。
您还可以执行以下操作：
您可以在这里做各种各样的事情。但是，要点是基本的搜索模式应该很容易满足需求。
I would just follow the classic search pattern used in many places.
http://example.org/word_statistics -- this would return everything, words and links, but you don't want to return everything, so you don't and instead return the appropriate error code with perhaps descriptions of what query options you do support. Or you could return everything, but in pages (10, 100, 1000 words at a time...).
http://example.org/word_statistics/{word} -- the statistics for the given word.
http://example.org/word_statistics?like=word -- this returns a list of words that are "like" word, this could handle misspelling and soundalikes, or whatever.
http://example.org/word_statistics?from_word=word1&to_word=word2 -- returns a list of words that starts, alphabetically, with from_word and goes to to_word, but under the same limit and paging constraints you'd have for the original list.
You could also do something like:
All sorts of things you can do here. But, the gist is that a basic search pattern should fill the need readily.