一時的なREST表現

私は、アイスクリームストアをモデル化した、RESTfulな、ハイパーテキスト駆動のサービスを持っているとしましょう。私の店舗をより良く管理するために、販売された各種類のアイスクリームの量とドル値を毎日表示するレポートを表示できるようにしたいと考えています。一時的なREST表現

このレポート機能は、DailyReportというリソースとして公開されるようです。 DailyReportは迅速に生成することができ、実際にサーバーにレポートを格納する利点はないようです。私はDailyReportをいくつかの日だけ必要とし、他の日はDailyReportを取得することに気をつけません。さらに、DailyReportsをサーバーに格納すると、クライアントの実装が複雑になるため、不要になったレポートを削除する必要があります。

DailyReportは一時的です。その表現は一度だけ取り出すことができます。これを実装する1つの方法は、 "/ daily-reports"というリンクを提供することです。このPOSTには、その日の売上に関する情報を記載したDailyReport表現を含む応答が返されます。

編集：私は本当にPOSTリクエストをしたいとしましょう。 DailyReportには、アイスクリームタイプをアルファベット順、ドル値 - 時間別ブレークダウン、またはオプションでその日の温度を含むソート、または特定のアイスクリームタイプ（リスト）を除外するなど、さまざまなビューを作成するためのさまざまなオプションがあります。 GETでクエリパラメータを使用するのではなく、適切なオプション（適切なカスタムメディアタイプを使用して各オプションを記録する）を使用してDailyReport表現をPOSTしたいと思います。私が返す表現は、レポートそのものと一緒に私のオプションを表示するでしょう。

これは問題について正しい考え方ですか、代わりに他の方法を使用する必要がありますか？正しい場合は、DailyReportリソースを実装する際に、特別な考慮事項が重要な場合があります。（たとえば、POST要求後に戻るときにLocationヘッダーを設定することはおそらく適切ではありません）。

出典

2009-08-20 Rich Apodaca

過去の日の日次レポートを利用可能にする場合は、/daily_reports/2009/08/20にGETとして実装することができます。 John Millikinによれば、POSTはここでは不要だと私は同意します。このようなものはユーザが作成できるリソースである必要はありません。

毎日のレポートを独自のURIとして利用できるというメリットは、キャッシュ可能性です。

EDIT：良い解決策がdaily_report/当日のデータのキャッシュなしの表現とdaily_reports/yyyy/mm/dd一日のデータのキャッシュ可能な表現を作り、2つの答えをマージするかもしれません。

出典

2009-08-20 22:10:37

は最近、 'daily_report'にパーマネントバージョンへの非永続的なリダイレクトを行ったことを除いて、このようなことをしました。 – xenoterracide

レポートをリクエストしてもサーバーの状態は変わらないので、これを行うにはPOSTを使用する必要はありません。あなたの編集への対応

GET /daily-report/ 

200 OK 
Pragma: no-cache 
<daily-report for="2009-04-20" generated-at="2009-4-20T12:13:14Z"> 
    <!-- contents of the report here --> 
</daily-report>

：私はこのようなリソース使用することになりますが、URLにレポートの説明を掲示し、その結果として設定され、一時的なデータを取得している場合は、それがでRESTではありませんすべて。 SOAPと同じようにRPCです。 RPCは本質的に悪いことではありませんが、RESTfulとは呼ばないでください。

出典

2009-08-20 22:08:44

良い点。たとえばDailyReportに適用できるいくつかのパラメータがある場合（たとえば、アルファベット順またはドル数値でソートする）、どうしたらクエリパラメータを使用したくないのですか？また、過去24時間以外の日付範囲、つまり一般的なレポートリソースに日付範囲を設定したい場合はどうすればよいですか？これらのオプションをクエリパラメータとして含めるのではなく、POSTペイロードとして送信される完全な表現として含めるとします。それは私が考えているものに近いです。 –

なぜクエリパラメータを使用したくないのですか？それが彼らの存在です。カスタムレポート範囲は、クエリパラメータを使用して提供することもできます。パラメータが複雑でクエリ文字列で表現できない場合は、パラメータをサーバにアップロードして日次レポートをサブリソースにする価値があります。 –

私はGreg's approachが正しいと思います。これを詳しく説明すると、毎週変更する/daily-reportリソースを提供する必要はありません。火曜日の午前11時59分にレポートを実行すると、水曜日の00:01に実行した場合とは異なる結果になるためです。クライアントはリソースが同じであることを期待し、B）クライアントは、1日が過ぎても前日のデータを取得できないようにします。利用可能な日次レポートごとに固有のリソース識別子を指定する必要があります。これにより、クライアントはいつでも必要な情報にアクセスできます。

出典

2009-08-20 22:16:48

/TodaysWeatherタイプのリソースを持つことはかなり一般的です。 GET間でリソースが変更されたときにクライアントに驚かされるべきではありません。 –

私はDarrelのコメントに同意します。ちょうど適切なexpiresヘッダーを追加してください。検索された時点までの何かを表すリソースを取得することは完全に有効です。 APIコンシューマーに明確にしたい場合は、別のURI形式を使用することをお勧めします。 /daily-report /archive/daily-reports/2009/02/12 誰かがジャンプしてRESTはURIの設計には関心がありませんが、使用可能なAPIを設計する上で重要です。 –

レポートのリクエストの記録を保持することが望ましい場合があります。その場合、コレクションリソースにPOSTするのは不合理ではありません。また、実行を非同期に処理する必要がある長期実行レポートの場合にも便利です。これらのレポート要求に対するサーバーの保有期間はあなた次第です。

私はオプションを含め、要求の表現を返します

POST /DailyReportRequests

ような何かをするだろう、とレポートは、レポート結果へのリンクが完了したとき。

事前に設定されたレポートがある場合に便利なもう1つの方法は、事前設定済みのレポートリンクのリストを含むDailyReportsリソースを作成することです。 OpenSearchDescription仕様では、Queryタグを使用してこれに類似することができます。

出典

2009-08-20 23:31:37

答えて

関連する問題