rest - 什么是大型数据集上下文中的 RESTful 资源，即天气数据？

Question

所以我正在开发一个网络服务来访问我们的天气预报数据(10000 个位置，每个 40 个参数，接下来 14 天的每小时值 = 大约 1.3 亿个值)。

因此，我阅读了有关 RESTful 服务及其意识形态的所有内容。

所以我知道一个 URL 正在处理一个资源。

但就我而言，什么是资源？

常见的用例是您希望在一个或多个位置的时间跨度内获取几个参数的数据。很明显，为每个值赋予其自己的 URL 是不切实际的，并且会导致数百个请求。我觉得我的具体问题并不完全适合 RESTful 模式。

更新:澄清一下:服务有两种使用模式。 1、原始数据；多个位置和参数的行和行数据。

解释数据；原始数据计算成符号(例如太阳和云)和其他参数。

没有一个“预测”。不同的客户对数据有不同的需求。

我认为这不适合 REST 模式的原因是，虽然我实际上可以拥有“预测”资源，但我仍然需要提交很多请求参数。因此，对资源的简单 GET 请求不起作用，我最终会在整个地方发布数据。

Answer 1

So I am working on a webservice to access our weather forecast data (10000 locations, 40 parameters each, hourly values for the next 14 days = about 130 million values). ... But what is a ressource in my case?

这取决于您的问题域的详细信息。仅仅拥有大量数据并不是避免 REST 的好理由。有聪明的方法和愚蠢的方法来建模和公开这些数据。

正如您所看到的，您此时的主要目标应该是了解资源到底是什么。对天气预报的了解只够关注天气 channel ，我在这里不会有太大帮助。这是为像您​​这样的领域专家打这个电话的。

如果您要更详细地解释您正在使用的主要领域概念，那么提供具体建议可能会更容易一些。

例如，一种资源可能是 Forecast。当天气预报员谈论预报时，会不断出现什么词？当您考虑将预测分解为更小的元素时，您会用什么词来描述这些部分？

递归地执行此过程，您可能能够列出重要术语。不要忘记这些术语可以描述事物或行为。想想这些术语的真正含义，可以使用哪些数据来建模它们，如何聚合它们。

至此，您将具备开始构建 RESTful 系统的条件——但不是在此之前。

不要忘记 RESTful 系统不是包装在 HTTP 中的数据转储 - 它是一个 hypertext-driven系统。

也不要忘记 media types是您的服务器与其客户端之间的联系点。媒体类型仅受您的想象力限制，如果您很聪明，它可以对任何大小的数据集进行建模。它可以包含 XML、JSON、YAML、Bloom Filter 等二进制元素，或者任何可以解决问题的东西。