什么是大型数据集上下文中的 RESTful 资源,即天气数据?
Posted
技术标签:
【中文标题】什么是大型数据集上下文中的 RESTful 资源,即天气数据?【英文标题】:What ist a RESTful-resource in the context of large data sets, i.E. weather data? 【发布时间】:2010-12-01 08:28:45 【问题描述】:所以我正在开发一个网络服务来访问我们的天气预报数据(10000 个位置,每个 40 个参数,接下来 14 天的每小时值 = 大约 1.3 亿个值)。
所以我阅读了有关 RESTful 服务及其意识形态的所有内容。
所以我知道一个 URL 正在处理一个资源。
但在我的情况下,是什么资源?
常见的用例是您希望在一个或多个位置的时间跨度内获取几个参数的数据。很明显,为每个值赋予其自己的 URL 是不切实际的,并且会导致数百个请求。我感觉我的具体问题并不完全适合 RESTful 模式。
更新:澄清:服务有两种使用模式。 1、原始数据;多个位置和参数的行和行数据。
-
解释数据;原始数据计算成符号(例如太阳和云)和其他参数。
没有一个“预测”。不同的客户对数据有不同的需求。
我认为这不符合 REST 模式的原因是,虽然我实际上可以拥有“预测”资源,但我仍然需要提交很多请求参数。因此,对资源的简单 GET 请求不起作用,我最终会在整个地方发布数据。
【问题讨论】:
【参考方案1】:所以我正在开发一个 Web 服务来访问我们的天气预报数据(10000 个位置,每个 40 个参数,接下来 14 天的每小时值 = 大约 1.3 亿个值)。 ...但是在我的情况下,资源是什么?
这取决于您的问题域的详细信息。仅仅拥有大量数据并不是避免 REST 的好理由。有聪明的方法和愚蠢的方法来建模和公开这些数据。
如您所见,您此时的主要目标应该是了解资源的确切含义。对天气预报的了解只够关注天气频道,我在这里不会有太大帮助。像您这样的领域专家可以打这个电话。
如果您要更详细地解释您正在使用的主要领域概念,可能会更容易提供具体建议。
例如,一种资源可能是 Forecast。当天气预报员谈论预报时,会不断出现什么词?当您考虑将预测分解为更小的元素时,您会用什么词来描述这些部分?
递归执行此过程,您可能能够列出重要术语。不要忘记这些术语可以描述事物或行为。想想这些术语的真正含义,可以使用哪些数据来建模它们,如何聚合它们。
此时,您将具备开始构建 RESTful 系统的条件 - 但不是在此之前。
不要忘记,RESTful 系统不是包装在 HTTP 中的数据转储 - 它是 hypertext-driven 系统。
也不要忘记media types 是您的服务器与其客户端之间的联系点。媒体类型仅受您的想象力限制,如果您很聪明,它可以对任何大小的数据集进行建模。它可以包含 XML、JSON、YAML、二进制元素(如 Bloom Filter)或任何能解决问题的东西。
【讨论】:
感谢您的意见,我试图在我的帖子中澄清一点。 @Christian,您的编辑表明没有“预测”-没问题。但真正的问题是:“预测”作为一个领域概念有多重要?同一个资源可以有多种表示,这取决于客户的需求,但资源是一个普遍适用的领域概念,可以独立于其表示进行建模。另一种说法:想象一个客户使用你的服务。他们想要创造什么或者他们想要做什么?【参考方案2】:首先,没有一劳永逸的正确答案。
每个有效的 url 都是有意义的查询,将它们视为为寻找您的数据的人提供查询表单的等价物 - 这可能会帮助您缩小范围。
这取决于个人喜好,也可能是您使用的工具包,至于基本 url 路径中的内容以及编码的参数。这场辩论有点像关于将值放入元素与属性中的 XML 辩论。这并不总是一个理性或逻辑决定的问题,也不会每个人都对你的决定友好。
如果您使用的是 Rails 之类的后端,则意味着某些 conventions。即使您不使用 Rails,也可以以相同的方式工作,除非您有充分的理由进行更改。这样,编写客户端以与基于 Rails 的服务对话的人会发现您的客户端更容易理解,并且可以节省您的文档时间;-)
【讨论】:
我知道这些约定,但我不知道如何在我的情况下应用它们。【参考方案3】:也许您可以使用预测作为资源,并通过 xlink 深入到细粒度的服务。
【讨论】:
【参考方案4】:有没有可能做这样的事情,因为你有这么多参数,所以我想如果你能以某种方式将它与 id / 参数组合的组合联系起来以减少 url 大小
/WeatherForeCastService//天/小时
【讨论】:
【参考方案5】:www.weatherornot.com/today/days/x // (where x is number of days)
www.weatherornot.com/today/9am/hours/h // (where h is number of hours)
【讨论】:
以上是关于什么是大型数据集上下文中的 RESTful 资源,即天气数据?的主要内容,如果未能解决你的问题,请参考以下文章
(预)处理存储在 json 中的大型数据集的最有效方法是啥?