rest - REST API とバイナリ リソースの配信

Question

REST API を使用してバイナリ リソース (pdf ファイルなど) を配信する規則は何ですか? {"url" : "http://example.com/document.pdf"} のように、JSON または XML 応答でリソースへの URL を返すだけですか?

URI と URL の違いを理解し、RESTful な哲学を維持しようとしています。確かに、これは私にとって初めてのことなので、いくつかのことを誤解している可能性があります。

Answer 1

このセクションでは、次のことを想定しています: バイナリ リソースの場所をユーザーに伝えるにはどうすればよいですか

URI と URL の違いは、バイナリ データ型と非バイナリ データ型とは何の関係もありません (も参照)。

主に JSON を返す場合は、urlエントリを使用するのが一般的です。もっと HTML/XML っぽいことをしているのであれば<link>、適切な属性を持つ要素のようなrelものは非常に理にかなっています。

明らかに、クライアントが指定GETした直接 URL にリクエストを送信した場合は、ファイルを送信する必要があります. その場合、406 Not Acceptable応答 (または公式の定義) は非常に理にかなっています。

あなたの質問で何か他のことを意味している場合は、明確にしてください。

とりとめのない「こうしよう」セクション

最初: URL と URI を無視します。これとは何の関係もありません。まったく。

次へ: 問題が「リソースにリンクするにはどうすればよいか」(これから説明する内容の影響を受ける可能性があります) ではなく、「リソースが単なる PDF ファイルの場合はどうなるか」である場合は、あらゆる種類のリソースがあります。それに対処するためのオプション。まず、一歩下がって、より抽象的に (少し) 考える必要があります。あなたのリソースはほぼ確実に「PDFファイル」ではありません。「ユーザーがアップロードしたファイル」や「私が生成したレポートの PDF 版」などです。

最初のケースでは、送信されたバイナリ以外にリソースの表現がない可能性がありますが、これはまったく問題ありません。GETそのリソースの URL を受け取ったときに、おそらくコンテンツ ネゴシエーションを実行する必要はありません。上記の注意事項に従って、ファイルを送信してください406。

2 番目のケースでは、このリソースのあらゆる種類の表現 (CSV、HTML、LaTeX など) がある可能性があります。この場合、GETリソースの URL を受け取ったときに、何らかのコンテンツ ネゴシエーションを行う必要があるため、PDF ドキュメントを送信するか、それ以外を送信するかがわかります。PDF を生成するために使用する単なる生データであるリソースの JSON 表現を持っている可能性があります。

どちらの場合でも、リソースに関する厳密なメタデータである表現があるとは予想外です。必要に応じて (多くの場合、そうでない場合もあります)、明示的な外部メタデータ (PDF の作成者やタイトル情報など、バイナリ リソース内に埋め込まれたメタデータとは対照的に) は、最も一般的には別のリソースとしてモデル化されます。

最後に、@monitorjbl が言うように、バイナリ データを JSON や XML などのテキスト形式に直接埋め込みたくないでしょう。多くの場合、「base64 エンコード」という言葉を含む方法がありますが、通常は最善の方法ではありません。一般に、バイナリ データとテキスト データを混在させるべきではありません。

Answer 2

バイナリであろうとなかろうと、RESTリソースはハイパーメディアタイプで記述されるべきです。

• RESTクライアントがmsgpack形式のPUT/POSTリソースを使用している場合でも、RESTサーバーはこのメッセージを読み取ってリソースを更新/作成できます。だから、なぜだろう。
• RESTクライアントがPDF形式のPUT/POSTリソースを使用している場合、リソースを適切に作成/更新するために必要なすべての情報を抽出することはできないと思います。だから、いや。

最後のケースでは、「Googleドライブ」のようなサービスを扱っている可能性があります。これらのPDFはそれ自体がリソースではなく、実際のリソースによってリンクされている必要があります（つまり、URLはリソース内にある必要があります）。

Googleドライブは完全なRESTAPI （APIリファレンス）ではない場合でも、JSONリソースと実際のバイナリファイルの両方を処理します。

Answer 3

私の経験では、それを行うことは、REST Web サービスの考え方とは正反対です。従来の RESTful サービスとは異なり、深刻な頭痛の種なしにこの応答をキャッシュすることはできません。また、XML/JSON を読み取るためにサービスをテキストとして使用する必要があるため、テキストとバイナリの読み取りの両方を最適化することはおそらくできません。言うまでもなく、常にバイナリ情報が必要になるか、テキスト データのみが必要な場合にパフォーマンスが大幅に低下します。また、常にバイナリ データが必要な場合は、なぜ Web サービスが必要なのかを自問してみてください。

これは、それが不可能だと言っているわけではありません (結局、BSON があります)、またはこれの使用例が存在しないと言っているわけではありませんが、試行する前に、バイナリ データに対して別の要求を強制することで逃れることができないことを十分に確認する必要があります。これをする。テキスト用に設計されたドキュメント形式にバイナリ データを埋め込むのは非常に非効率的です。この形式のデータは、生のバイトの場合よりもはるかに大きくなります。

余談ですが、SVG や特定の種類の PDF などのベクトル グラフィック リソースを常に使用している場合は、それを XML データとして表すことができます。繰り返しますが、ペイロードが増えるため、したくないかもしれませんが、「必要なバイナリ」を回避するためのオプションです。