2

RESTful アプリケーションでは、「リソース」URL を使用して JSON データとデータにアクセスするページの両方を提供することは良い考えですか? そうでない場合、2つのことをどのように区別すればよいですか?

ページ/routesがあり、すべてのルートを一覧表示するページがあるとします。私はこれを行う必要があります:

HTML ページ

GET /routes
Accept: text/html

Response:
<h1>Routes</h1>
<p>blah blah blah</p>
... <table></table>
<script>
    $.getJSON('/routes').done(insertDataIntoTable);
</script>

JSON レスポンス

GET /routes
Accept: application/json

Response:
[
    {"number": "95", "start": "Place d'Orléans", "end": "Barrhaven Centre"},
    {"number": "96", "start": "Hurdman", "end": "Kanata"},
    {"number": "97", "start": "Bayshore", "end": "Airport/Aéroport"},
    /* etc... */
]

2 つの要求が同じ URL/URI に対して行われているため、これは間違っているように見えますが、異なるリソースが返されます (1 つはアプリケーション ページで、もう 1 つはデータです)。次のようなものを提供する方が適切と思われますAccept: text/html:

GET /routes
Accept: text/html

Response:
<table>
    <thead>
        <tr><th>Number</th><th>Start</th><th>End</th></tr>
    </thead>
    <tr><td>95</td><td>Place d'Orléans</td><td>Barrhaven Centre</td></tr>
    <!-- etc... -->
</table>

（あまり役に立たないので、おそらくやらないでしょう。）

私はいくつかのオプションについて考えました：

  1. Accept上記のように HTTP ヘッダーを使用します
  2. クエリ パラメータを使用する (例: /routes?type=html)
  3. ページに別のパスを使用する (例:/routesデータ/pages/routes用とアプリケーション用)
  4. 拡張機能を使用する (例:/routesデータ用および/routes.phpアプリケーション用)

1 と 2 はあまり正しくないようです。ページはそれ自体がリソースであり、アプリケーション内のエンティティを正確に表しているわけではありませんが、私は 3 にあまり熱心ではありません。オプション 4 は単純に醜く見えます。

主要なサイトが何をしているかを調べてみましたが、それらはすべて別のホスト/サブドメイン (例: facebook.com/ graph.facebook.com、twitter.com/ api.twitter.com) からデータを提供していますが、これは私にとって選択肢ではありません。

何か案は？この質問は主に意見に基づくものであってはならないので、参考にしていただければ幸いです。

4

2 に答える 2

0

HTML ページは API のリソースとは異なるタイプのリソースであるため、番号 4 が最適なオプションのように見えます。ページを API リソースから分離することは良い考えのようです。
Twitter と Facebook の例も、このアプローチをサポートしています。

于 2014-08-19T03:56:24.793 に答える
0

HTTP Accept ヘッダーを使用できます。これにより、実行時のコンテンツ ネゴシエーションが可能になります。http://docs.oracle.com/javaee/6/tutorial/doc/gkqbq.htmlを参照 してください
。ただし、json 応答用の /routes.json とすぐに使用できる html 用の /routes.html のような 2 つの別個の URL を使用することをお勧めします。

于 2014-08-19T04:11:34.250 に答える