10年以上経過した後、OPで要求されているようなものをRESTアーキテクチャーでどのように設計できるかについての答えが実際にはないので、少し悲しいです。
まず最初に、RESTとは何ですか？頭字語RESTまたはReSTは「Representational State Transfer」の略で、リソースの状態の交換を特定の表現形式で定義します。表現形式は、ネゴシエートされたメディアタイプに対応しています。以下の場合にapplication/html表現形式HTMLのストリームは、おそらく特定の場所で特定の要素を配置するフォーマットいくつかのスタイルシートを適用した後、ブラウザに表示されるテキストコンテンツをフォーマットすることができます。
RESTは原則として、私たちが知っているブラウズ可能なWebを一般化したものですが、ブラウザーだけでなくあらゆる種類のアプリケーションを対象としています。したがって、設計上、Webに適用されるのと同じ概念がRESTアーキテクチャにも適用されます。「RESTful」な方法で何かを達成する方法のような質問は、Webページで何かを達成する方法の質問に答えてから、同じ概念をアプリケーション層に適用することで解決します。
通常、Webベースの計算機は、入力したデータをサーバーに送信する前に計算する値を入力できる「ページ」から開始する場合があります。HTMLでは、これは通常<form>、設定可能なパラメーター、要求の送信先のターゲットの場所、および入力データの送信時に適用する表現形式についてクライアントに教えるHTML 要素によって実現されます。つまり、次のようになります。
<html>
<head>
...
</head>
<body>
<form action="/../someResource" method="post" enctype="application/x-www-form-urlencoded">
<label for="firstNumber">First number:</label>
<input type="number" id="firstNumber" name="firstNumber"/>
<label for="secondNumber">Second number:</label>
<input type="number" id="secondNumber" name="secondNumber"/>
<input type="submit" value="Add numbers"/>
</form>
</body>
</html>
上記のサンプルは、ユーザーまたは他のオートマトンによって入力できる2つの入力フィールドがあり、送信入力要素を呼び出すと、ブラウザーが入力データを送信されるapplication/x-www-form-urlencoded表現形式にフォーマットすることを処理することを示していますPOSTこの場合、指定されたHTTPリクエストメソッドを介して上記のターゲットの場所に送信されます。私たちが入力した場合1にfirstNumber、入力フィールドと2にsecondNumber入力フィールド、ブラウザは、の表現を生成しますfirstNumber=1&secondNumber=2し、ターゲットリソースへの実際のリクエストのボディのペイロードとしてこれを送ります。
したがって、サーバーに発行された生のHTTPリクエストは次のようになります。
POST /../someResource
Host: www.acme.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept: application/html
firstNumber=1&secondNumber=2
サーバーは計算を実行し、クライアントがこの形式を理解していることを要求が示しているので、計算の結果を含む追加のHTMLページで応答します。
ブルトンがすでに指摘したように、「RESTful」なURLやURIなどはありません。URI / URLは独自の種類のものであり、クライアント/ユーザーに意味を伝えるべきではありません。上記の計算機サンプルでは、ユーザーはデータをどこに送信するかを単に興味がありませんが、送信入力フィールドをトリガーするとリクエストが送信されることに興味があります。タスクを実行するために必要なすべての必要な情報は、サーバーによってすでに提供されているはずです。
ブラウザはまた、リクエストが実際に計算機にいくつかの入力パラメータを供給していることを認識していない可能性があります。これは、注文プロセスを続行するために次のフォーム表現のみを返す注文フォームの場合もあれば、まったく異なる種類の場合もあります。資源。そのような場合にHTML仕様が要求することを実行するだけで、サーバーが実際に何をしているのかを気にすることはできません。このコンセプトにより、ブラウザは同じ表現形式を使用して、好みのオンラインショップからの注文、親友とのチャット、オンラインアカウントへのサインインなど、あらゆる種類のことを実行できます。
通常はボタンとしてレンダリングされる送信入力フィールドの場合など、特定の要素のアフォーダンスは、それをどうするかを定義します。ボタンやリンクの場合、基本的にそれをクリックするように指示します。他の要素は異なるアフォーダンスを伝えるかもしれません。このようなアフォーダンスは、リンク関係を介して表現することもできpreloadます。つまり、ユーザーが次のコンテンツを取得する可能性が最も高いため、リンクされたリソースのコンテンツをバックグラウンドで既にロードできることをクライアントに基本的に伝える注釈付きリンクを使用して表現できます。もちろん、このようなリンク関係は標準化するか、Webリンクで定義されている関係タイプの拡張メカニズムに従う必要があります。
これらはWebで使用される基本的な概念であり、RESTアーキテクチャでも使用する必要があります。"Uncle Bob" Robert C. Martinによれば、アーキテクチャーは意図的なものであり、RESTアーキテクチャーの背後にある意図は、サーバーをクライアントから切り離して、サーバーがクライアントを壊すことを恐れずに自由に進化できるようにすることです。残念ながら、カップリングを導入したり、クイックフィックスソリューションを追加して作業を完了したりするのは非常に簡単であるため、多くの訓練が必要です。Jim WebberがRESTアーキテクチャで指摘したように、サービスプロバイダーは、70年代のテキストベースのコンピューターゲームと同様のドメインアプリケーションプロトコルを設計して、クライアントがプロセスの最後に到達するまで追跡する必要があります。
残念ながら、いわゆる「REST」APIの多くは、残念ながら実際には何もしていません。API固有の外部ドキュメントで指定されている、主にJSONベースのデータの交換が表示されますが、その場で動的に統合することは通常困難です。リクエストがどのように見える必要があるかの形式も外部ドキュメントにハードコードされているため、事前定義されたtypを返す URIを解釈する多くの実装につながります。事前に交渉される一般的な表現形式を使用する代わりに。これにより、クライアントが事前定義されたURIの特定のデータ形式（表現形式ではないことに注意してください！）を受け取ることを期待するため、サーバーが変更されるのを防ぎます。「データ形式」は通常特定のAPIに対応しているため、このカスタムデータ形式の交換により、クライアントが他のAPIとやり取りすることがさらに防止されます。最近、Peppolがデフォルトの転送プロトコルとしてAS2をAS4に置き換えることによって再びそれに移行したとしても、Corba、RMI、SOAPなどのRPCテクノロジから過去のこの概念を知っています。
実際に尋ねられる質問に関しては、データをcsvファイルとして送信することは、application/x-www-form-urlencoded表現または類似のものを使用することと何の違いもありません。ジムウェバーは、結局のところ、HTTPは単なるトランスポートプロトコルであり、そのアプリケーションドメインはWebを介したドキュメントの転送であることを明らかにしました。クライアントとサーバーは、少なくとも両方ともRFC 7111でtext/csv定義されているようにサポートする必要があります。このCSVファイルは、リクエストを送信するフォーム要素、ターゲット要素、または属性を定義するメディアタイプと、設定のアップロードを実行するHTTPメソッドを処理した結果として生成される可能性があります。
HTML、HALフォーム、halform、ion、Hydraなどのフォームをサポートするメディアタイプがいくつかあります。ただし、現在、入力データをtext/csv直接自動的にエンコードできるメディアタイプを認識していないため、IANAのメディアタイプレジストリで定義および登録する必要がある場合があります。
完全なパラメータセットのアップロードとダウンロードは、私が推測する問題ではないはずです。前述のように、クライアントはURIを使用して新しいコンテンツを取得して処理するため、ターゲットURIは関係ありません。営業日によるフィルタリングも難しくありません。ただし、サーバーは、クライアントが選択できるすべての可能性を備えたクライアントである必要があります。近年、GraphQLとRestQLが進化し、特定のエンドポイントをターゲットにしてフィルタリングされた応答を取得できるSQLのような言語が導入されました。ただし、本当のRESTの意味では、これはRESTの背後にあるアイデアに違反します。a）GraphQLは、単一のエンドポイントのみを使用して、何らかの理由でキャッシュの最適な使用を妨げ、b）利用可能なフィールドの知識を必要とするため、クライアントの結合の導入につながる可能性があります。リソースの基本データモデルに。
特定の構成パラメーターをアクティブ化または非アクティブ化するには、このアフォーダンスを提供するハイパーメディアコントロールをトリガーするだけです。HTMLフォームでは、これは単純なチェックボックスか、リストまたはその種類の複数行の選択です。フォームとそれが定義するメソッドに応じて、構成全体を送信するPUTか、行われた変更についてスマートになり、を介して部分的な更新のみを実行する可能性がありますPATCH。後者は基本的に、更新された表現への変更表現の計算を必要とし、現在の表現を目的の表現に変換するために必要な手順をサーバーに提供します。PATH仕様によれば、これはトランザクション内で実行する必要があるため、すべてのステップが適用されるか、いずれのステップも適用されません。
HTTPは、変更を適用する前に、サーバーが受信した要求を事前に検証することを許可および推奨します。以下のためのPUTスペックの状態：
オリジンサーバーは、PUT表現が、PUTによって変更できない、または変更されないターゲットリソースに対するサーバーの制約と整合していることを確認する必要があります（SHOULD）。オリジンサーバーがURIに関連する内部構成情報を使用してGET応答の表現メタデータの値を設定する場合、これは特に重要です。PUT表現がターゲットリソースと矛盾している場合、オリジンサーバーは、表現を変換するかリソース構成を変更してそれらを一貫させるか、表現が不適切である理由を説明する十分な情報を含む適切なエラーメッセージで応答する必要があります（SHOULD）。409（競合）または415（サポートされていないメディアタイプ）ステータスコードが推奨されます。
たとえば、ターゲットリソースが常に "text / html"のContent-Typeを持つように構成され、PUTである表現が "image / jpeg"のContent-Typeを持つ場合、オリジンサーバーは次のいずれかを実行する必要があります。
a。新しいメディアタイプを反映するようにターゲットリソースを再構成します。
b。新しいリソース状態として保存する前に、PUT表現をリソースの形式と一致する形式に変換します。または、
c。ターゲットリソースが「text / html」に制限されていることを示す415（Unsupported Media Type）応答でリクエストを拒否します。おそらく、新しい表現の適切なターゲットとなる別のリソースへのリンクが含まれます。
HTTPは、PUTメソッドがオリジンサーバーの状態にどのように影響するかを、ユーザーエージェント要求の意図とオリジンサーバーの応答のセマンティクスを超えて正確に定義していません。...
この投稿を要約すると、必須またはサポートされている入力パラメーター、リクエストを送信するターゲットの場所、使用する操作、およびメディアタイプをクライアントに教えることができる既存のメディアタイプを使用する必要があります。リクエストをフォーマットするか、IANAに登録する独自のリクエストを定義する必要があります。入力を次のように変換する場合は、後者が必要になることがあります。text/csv次に、CSV表現をサーバーにアップロードします。検証は、変更がリソースに適用される前に行う必要があります。実際のURIは、リクエストをどこに送信するかを決定する以外のクライアントに関連していてはならず、サービスの実装者であるあなたが自由に選択することができます。これらの手順に従うことで、いつでもサーバー側を変更できる自由が得られ、クライアントが使用されているメディアタイプをサポートしていれば、結果としてクライアントが壊れることはありません。