在大数据集（即天气数据）背景下，什么是 RESTful 资源？
因此，我正在开发一个 Web 服务来访问我们的天气预报数据（10000 个位置，每个位置 40 个参数，接下来 14 天的每小时值 = 大约 1.3 亿个值）。
所以我阅读了有关 RESTful 服务及其意识形态的所有内容。
所以我理解 URL 是指资源。
但在我的例子中，什么是资源呢？
常见的用例是您想要获取一段时间内一个或多个位置的几个参数的数据。因此，明确为每个值提供自己的 URL 是不切实际的，并且会导致数百个请求。我感觉我的具体问题并不完全符合 RESTful 模式。
更新：澄清一下：该服务有两种使用模式。 1、原始数据；多个位置和参数的行和数据行。
- 解释数据；将原始数据计算为符号（例如太阳和云）和其他参数。
没有一个“预测”。不同的客户对数据有不同的需求。
我认为这不适合 REST 模式的原因是，虽然我实际上可以拥有“预测”资源，但我仍然必须提交大量请求参数。因此，对资源的简单 GET 请求不起作用，我最终会在各处发布数据。
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).
So I read all about RESTful services and its ideology.
So I understand that an URL is adressing a ressource.
But what is a ressource in my case?
The common use case is that you want to get the data for a couple of parameters over a timespan at one or more location. So clearly giving every value its own URL is not pratical and would result in hundreds of requests. I have the feeling that my specific problem doesn't excactly fit into the RESTful pattern.
Update: To clarify: There are two usage patterns of the service. 1. Raw data; rows and rows of data for several locations and parameters.
- Interpreted data; the raw data calculated into symbols (Suns & clouds, for example) and other parameters.
There is not one 'forecast'. Different clients have different needs for data.
The reason I think this doesn't fit into the REST-pattern is, that while I can actually have a 'forecast' ressource, I still have to submit a lot of request parameters. So a simple GET-request on a ressource doesn't work, I end up POSTing data all over the place.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于您的问题域的详细信息。仅仅拥有大量数据并不是避免 REST 的充分理由。建模和公开数据有聪明的方法和愚蠢的方法。
正如您所看到的，您此时的主要目标应该是了解资源到底是什么。我对天气预报的了解只够关注天气频道，在这里我不会有太大帮助。像您这样的领域专家应该做出这样的决定。
如果您要更详细地解释您正在使用的主要领域概念，可能会更容易给出具体建议。
例如，一种资源可能是 Forecast。当天气预报员谈论天气预报时，经常会出现哪些词？当您考虑将预测分解为更小的元素时，您会使用什么词来描述这些部分？
递归地执行此过程，您可能能够列出重要术语。不要忘记这些术语可以描述事物或行为。思考这些术语的真正含义，您可以使用哪些数据来对它们进行建模，以及如何聚合它们。
此时，您将具备可以开始构建 RESTful 系统的条件 - 但在此之前还不行。
不要忘记，RESTful 系统不是封装在 HTTP 中的数据转储 - 它是一个 超文本驱动系统。
另外不要忘记媒体类型是服务器与其客户端之间的联系点。媒体类型仅受您的想象力限制，如果您足够聪明，它可以对任何大小的数据集进行建模。它可以包含 XML、JSON、YAML、二进制元素（例如 Bloom Filter）或任何能解决问题的元素。
That depends on the details of your problem domain. Simply having a large amount of data is not a good reason to avoid REST. There are smart ways and dumb ways to model and expose that data.
As you rightly see, your main goal at this point should be to understand what exactly a resource is. Knowing only enough about weather forecasting to follow the Weather Channel, I won't be much help here. It's for domain experts like yourself to make that call.
If you were to explain in a little more detail the major domain concepts you're working with, it might make it a little easier to give specific advice.
For example, one resource might be Forecast. When weatherpeople talk about Forecasts, what words keep coming up? When you think about breaking a forecast down into smaller elements, what words do you use to describe the pieces?
Do this process recursively, and you'll probably be able to make a list of important terms. Don't forget that these terms can describe things or actions. Think about what these terms really mean, what data you can use to model them, how they can be aggregated.
At this point you'll have the makings of something you can start building a RESTful system around - but not before.
Don't forget that a RESTful system is not a data dump wrapped in HTTP - it's a hypertext-driven system.
Also don't forget that media types are the point of contact between your server and its clients. A media type is only limited by your imagination and can model datasets of any size if you're clever about it. It can contain XML, JSON, YAML, binary elements such as a Bloom Filter, or whatever works for the problem.
首先，没有一劳永逸的正确答案。
每个有效的 url 都是对查询有意义的东西，将它们视为相当于为寻找您的数据的人提供查询表单 - 这可能会帮助您缩小场景范围。
至于基本 url 路径中包含哪些内容以及编码哪些参数，这取决于个人品味，也可能取决于您使用的工具包。这场争论有点像关于将值放入元素与属性中的 XML 争论。这并不总是一个理性或逻辑决定的问题，每个人也不会善意地对你的决定发表评论。
如果您使用的是 Rails 之类的后端，则意味着某些约定。即使您不使用 Rails，以同样的方式工作也是有意义的，除非您有充分的理由进行更改。这样，编写客户端与基于 Rails 的服务进行交互的人会发现您的服务更容易理解，并且可以节省您的文档时间;-)
Firstly, there is no once-and-for-all right answer.
Each valid url is something that makes sense to query, think of them as equivalents to providing query forms for people looking for your data - that might help you narrow down the scenarios.
It is a matter of personal taste and possibly the toolkit you use, as to what goes into the basic url path and what parameters are encoded. The debate is a bit like the XML debate over putting values in elements vs attributes. It is not always a rational or logically decided issue nor will everybody be kind in their comments on your decisions.
If you are using a backend like Rails, that implies certain conventions. Even if you're not using Rails, it makes sense to work in the same way unless you have a strong reason to change. That way, people writing clients to talk to Rails-based services will find yours easier to understand and it saves you on documentation time ;-)
也许您可以使用预测作为资源，并通过 xlink 更深入地了解细粒度服务。
Maybe you can use forecast as the ressource and go deeper to fine grained services with xlink.
是否可以做这样的事情，因为你有这么多参数，所以我想如果你能以某种方式将它与 id / 参数组合的混合联系起来，以减少 url 大小
/WeatherForeCastService//day/hour
Would it be possible to do something like this,Since you have so many parameters so i was thinking if somehow you can relate it to a mix of id / parameter combo to decrease the url size
/WeatherForeCastService//day/hour