所以我正在开发一个网络服务来访问我们的天气预报数据（10000个地点，每个40个参数，接下来14天的每小时值=约1.3亿个值）。
所以我读了所有关于RESTful服务及其意识形态的内容。
所以我理解一个URL正在处理一个资源。
但在我的案例中是的资源？
常见的用例是，您希望在一个或多个位置的时间跨度内获取几个参数的数据。因此，清楚地给每个值提供自己的URL并不是实际的，并且会导致数百个请求。我觉得我的具体问题并不完全符合RESTful模式。
更新：澄清一下：该服务有两种使用模式。 1.原始数据;多个位置和参数的行和行数据。
没有一个'预测'。不同的客户对数据有不同的需求。
我认为这不符合REST模式的原因是，虽然我实际上可以有一个'预测'资源，但我仍然需要提交大量的请求参数。因此，对资源的简单GET请求不起作用，我最终在整个地方发布数据。
答案 0 :(得分：3)
所以我正在开发一个网络服务来访问我们的天气预报数据（10000个地点，每个40个参数，接下来14天的每小时值=约1.3亿个值）。 ......但在我的案例中，什么是资源？
这取决于您的问题域的详细信息。简单地拥有大量数据并不是避免REST的好理由。有模拟和公开数据的聪明方法和愚蠢方法。
正如您所看到的，此时您的主要目标应该是了解资源究竟是什么。只知道天气预报跟随天气频道，我在这里不会有太多帮助。像你这样的领域专家可以打电话。
如果您要更详细地解释您正在使用的主要域概念，可能会更容易提供具体的建议。
例如，一种资源可能是预测。当天气预报员谈论预测时，会出现什么词？当您考虑将预测分解为更小的元素时，您使用什么词来描述这些元素？
递归执行此过程，您可能能够列出重要的术语。不要忘记这些术语可以描述事物或行为。想想这些术语到底意味着什么，您可以使用哪些数据对它们进行建模，以及如何汇总这些数据。
此时你将拥有一些可以开始构建RESTful系统的东西 - 但不是之前。
不要忘记RESTful系统不是HTTP中包含的数据转储 - 它是hypertext-driven系统。
另外请不要忘记media types是服务器与其客户端之间的联系点。媒体类型仅受您的想象力限制，如果您对它有所了解，可以对任何大小的数据集进行建模。它可以包含XML，JSON，YAML，二进制元素，如Bloom Filter，或者适用于该问题的任何内容。
答案 1 :(得分：1)
首先，没有一劳永逸的正确答案。
每个有效网址都是有意义的查询，将其视为为查找数据的人提供查询表单的等效内容 - 这可能有助于缩小方案范围。
这是个人品味的问题，也可能是您使用的工具包，关于基本URL路径的内容以及编码的参数。辩论有点像关于在元素与属性中放置值的XML争论。它并不总是一个理性或逻辑上决定的问题，也不会每个人都对你的决定发表评论。
如果您使用像Rails这样的后端，则意味着某些conventions。即使您没有使用Rails，除非您有充分的理由进行更改，否则以相同的方式工作是有意义的。这样，编写客户端与基于Rails的服务交谈的人会发现您更容易理解，并节省了文档时间; - ）
答案 2 :(得分：0)
也许您可以使用预测作为资源，并使用xlink深入了解细粒度服务。
答案 3 :(得分：0)
是否有可能做这样的事情，因为你有这么多的参数，所以我在想，如果不知怎的话，你可以把它与id /参数组合混合以减少网址大小
/ WeatherForeCastService //日/小时
答案 4 :(得分：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)