私は現在、純粋にリソース指向のエンタープライズ サービスを設計しています。いくつかのブログや本などを読んだ後、ハイパーメディア リンクを使用した REST が最適だと思います。
ただし、これらすべてのブログや書籍で言われていることの 1 つは、応答でハイパーメディア リンクを使用する場合、メディア タイプとして application/xml を使用しないことです。次のような一般的なステートメントを除いて、誰も理由を述べていません-リンク関係タイプのないプレーンなURIは、URIのセマンティクスをクライアントに伝えません。
私が理解したことから、独自のカスタム メディア タイプを定義し、それを読み取る方法をクライアントに認識させることが推奨されるアプローチです。しかし、私のサービスに接続するクライアントが決してブラウザーではないことがわかっている場合、それは問題になるでしょうか? application/xml タイプの応答でこれらのリンクを公開することはできませんか?
ここの誰かがこれについてもっと詳しく説明してくれることを願っていました。
カスタム メディア タイプを使用する必要はありません。実際、REST は過度に具体的なメディア タイプを作成することを思いとどまらせようとします。理想は、メディア タイプがセマンティック情報を伝達する必要がありますが、特定のサービスに固有のものではないということです。
application/xml の問題の 1 つは、リンクがどのように見えるかについての標準的な定義がないことです。それは...ですか
<Link rel="foo" href="/foo">
またはそれは
<foo href="/foo">
または他の変種？クライアントは、「帯域外」の知識を使用せずに、文書内に存在するリンクを特定する方法をどのように知ることができますか? 「アウト オブ バンド」ナレッジは避けたいものです。これは、サーバーが変更を加えたときにクライアントが壊れる原因となり、クライアントはアウト オブ バンド ナレッジへの変更から自身を保護できないためです。
もう 1 つの問題application/xmlは、要素と属性の階層以外のセマンティクスが含まれていないことです。セマンティクスは、メディア タイプまたはリンク関係によって伝達される必要があります。使用する場合application/xmlは、リンク関係を使用して、クライアントにそのドキュメントの消費方法を伝える必要があります。
リンク関係とメディア タイプでセマンティクスを伝えることの間には、適切なバランスが取れている可能性があります。しかし、正直なところ、業界はそのバランスが何であるかを正確に把握しようとしており、このテーマについてさまざまな意見を持っている人がたくさんいます.
application/hal+xmlを見ることをお勧めします。一般的な XML に最も近いものですが、リンク セマンティクスが定義されています。