5

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

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

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

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

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

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

  1. 解释数据；原始数据计算成符号（例如太阳和云）和其他参数。

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

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

4

5 回答 5

3

所以我正在开发一个网络服务来访问我们的天气预报数据（10000 个位置，每个 40 个参数，接下来 14 天的每小时值 = 大约 1.3 亿个值）。...但是在我的情况下，资源是什么？

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

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

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

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

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

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

不要忘记 RESTful 系统不是包装在 HTTP 中的数据转储——它是一个超文本驱动的系统。

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

于 2009-09-26T14:14:59.060 回答
1

首先，没有一劳永逸的正确答案。

每个有效的 url 都是有意义的查询，将它们视为为寻找您的数据的人提供查询表单的等价物 - 这可能会帮助您缩小方案范围。

关于基本 url 路径中的内容以及编码的参数，这是个人喜好问题，也可能是您使用的工具包。这场辩论有点像关于将值放入元素与属性中的 XML 辩论。这并不总是一个理性或逻辑决定的问题，每个人都不会对你的决定发表评论。

如果您使用像 Rails 这样的后端，这意味着某些约定。即使您不使用 Rails，也可以以相同的方式工作，除非您有充分的理由进行更改。这样，编写客户端以与基于 Rails 的服务交谈的人会发现您的客户端更容易理解，并且可以节省您的文档时间；-)

于 2009-09-26T07:01:35.380 回答
0

也许您可以使用预测作为资源，并使用 xlink 更深入地了解细粒度服务。

于 2009-09-25T08:27:44.910 回答
0

是否有可能做这样的事情，因为你有这么多参数所以我在想如果你能以某种方式将它与 id / 参数组合的组合联系起来以减少 url 大小

/WeatherForeCastService//天/小时

于 2009-09-25T20:19:42.287 回答
0 
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)
于 2009-09-25T20:24:19.897 回答