5

そのため、天気予報データ (10000 の場所、それぞれ 40 のパラメーター、次の 14 日間の時間値 = 約 1 億 3000 万の値) にアクセスするための Web サービスに取り組んでいます。

そこで、RESTful サービスとそのイデオロギーについてすべて読みました。

URLがリソースをアドレス指定していることを理解しています。

しかし、私の場合、リソースとは何ですか?

一般的な使用例は、1 つまたは複数の場所で一定期間にわたっていくつかのパラメーターのデータを取得する場合です。そのため、すべての値に独自の URL を明確に指定することは実用的ではなく、何百ものリクエストが発生することになります。私の特定の問題は、RESTful パターンに正確に適合しないと感じています。

更新:明確にするために: サービスには 2 つの使用パターンがあります。1.生データ; いくつかの場所とパラメーターのデータの行と行。

  1. 解釈されたデータ; シンボル (太陽と雲など) およびその他のパラメーターに計算された生データ。

「予測」は一つではありません。クライアントが異なれば、データに対するニーズも異なります。

これが REST パターンに適合しないと私が考える理由は、実際には「予測」リソースを使用できますが、多くの要求パラメーターを送信する必要があるためです。そのため、リソースに対する単純な GET リクエストは機能せず、データをいたるところに POST することになります。

4

5 に答える 5

3

そのため、天気予報データ (10000 の場所、それぞれ 40 のパラメーター、次の 14 日間の時間値 = 約 1 億 3000 万の値) にアクセスするための Web サービスに取り組んでいます。...しかし、私の場合、リソースとは何ですか?

それは、問題のドメインの詳細によって異なります。単純に大量のデータを持つことは、REST を回避する正当な理由にはなりません。そのデータをモデル化して公開するスマートな方法とばかげた方法があります。

当然のことながら、この時点での主な目標は、リソースが正確に何であるかを理解することです。Weather Channel をフォローする程度の天気予報しか知らないので、ここではあまり役に立ちません。あなたのようなドメインの専門家がその電話をかけてください。

あなたが取り組んでいる主要なドメインの概念をもう少し詳しく説明すると、具体的なアドバイスをするのが少し簡単になるかもしれません。

たとえば、1 つのリソースが Forecast である場合があります。気象関係者が予報について話すとき、どの言葉がよく出てきますか? 予測をより小さな要素に分割することを考えるとき、その要素を説明するためにどのような言葉を使用しますか?

このプロセスを再帰的に行うと、おそらく重要な用語のリストを作成できるでしょう。これらの用語が物や行動を説明できることを忘れないでください。これらの用語の本当の意味、モデル化に使用できるデータ、集計方法について考えてください。

この時点で、RESTful システムの構築を開始できるものの作成が完了しますが、それ以前ではありません。

RESTful システムは、HTTP でラップされたデータ ダンプではないことを忘れないでください。これは、ハイパーテキスト駆動型のシステムです。

また、メディア タイプはサーバーとそのクライアント間の接点であることも忘れないでください。メディア タイプはあなたの想像力によってのみ制限され、賢く使えばあらゆるサイズのデータ​​セットをモデル化できます。これには、XML、JSON、YAML、ブルーム フィルターなどのバイナリ要素、または問題に有効なものを含めることができます。

于 2009-09-26T14:14:59.060 に答える
1

まず、絶対的な正解はありません。

それぞれの有効な URL は、クエリを実行するのに意味のあるものです。それらは、データを探している人にクエリ フォームを提供することと同等であると考えてください。これは、シナリオを絞り込むのに役立つ場合があります。

基本的な URL パスに何が入り、どのパラメーターがエンコードされるかは、個人的な好みの問題であり、おそらく使用するツールキットの問題でもあります。この議論は、要素と属性に値を入れることに関する XML の議論に少し似ています。それは常に合理的または論理的に決定された問題ではなく、あなたの決定に対して誰もが親切にコメントしてくれるわけではありません.

Rails のようなバックエンドを使用している場合、それは特定の規則を意味します。Rails を使用していない場合でも、変更する強い理由がない限り、同じ方法で作業することは理にかなっています。そうすれば、Rails ベースのサービスと対話するクライアントを書いている人は、あなたのクライアントが理解しやすくなり、ドキュメント作成の時間を節約できます ;-)

于 2009-09-26T07:01:35.380 に答える
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 に答える
0

おそらく、リソースとして予測を使用し、xlink を使用してきめ細かいサービスに進むことができます。

于 2009-09-25T08:27:44.910 に答える