7

ここでは、ビジネス パートナーに XML フィードを提供するボックスがあります。フィードのリクエストは、クエリ文字列のパラメーターと値を指定することでカスタマイズされます。これらのパラメーターの一部は必須ですが、多くは必須ではありません。

たとえば、パートナーを識別するためにすべての要求で GUID を指定する必要があり、要求は「最新の取得」アクションまたは「検索」アクションのいずれかになります。

検索の場合: http://services.null.ext/?id=[GUID]&q=[検索キーワード]
カテゴリの最新データ: http://services.null.ext/?id=[GUID]&category=[ ID】

これらのパラメーターの RESTful URL スキームを構築するのは簡単です。

検索: http://services.null.ext/[GUID]/search/[キーワード]
最新: http://services.null.ext/[GUID]/latest/category/[ID]

しかし、私たちが持っている十数個のオプションのパラメーターをどのように処理すればよいのでしょうか? これらの多くは相互に排他的であり、多くは組み合わせが必要です。非常に急速に、可能なパスの数は圧倒的に複雑になります。

複雑なクエリ文字列を含む URL をより使いやすい /REST/ful/paths にマップする方法について、推奨される方法は何ですか?

(規約、スキーム、パターンなどに興味があります。Web サーバーまたはフレームワークで URL 書き換えを実装するための特定のテクノロジではありません。)

4

2 に答える 2

4

オプションのクエリパラメータはクエリ文字列に残しておく必要があります。RESTには、クエリ文字列が存在できないことを示す「ルール」はありません。実際、それはまったく逆です。クエリ文字列は、クライアントに転送する表現のビューを変更するために使用する必要があります。

URLパスコンポーネントについては、「表現可能な状態のエンティティ」に固執してください。カテゴリは問題ないようですが、XMLをフィードしているのは正確には何ですか？投稿？カタログアイテム？部品？

はるかに優れたREST分類法は次のようになると思います（XMLフィードのコンテンツが「記事」であると仮定します）。

REST構造を構築するときに表現しているエンティティについて考えていない場合は、RESTを実行していません。あなたは何か他のことをしています。

RESTのベストプラクティスに関するこの記事をご覧ください。古いですが、役立つかもしれません。

于 2008-10-03T20:15:06.597 に答える
1

値を持つパラメータ? 1 つのオプションはクエリ文字列です。それを使用することは、本質的に安らかではありません。もう 1 つのオプションは、セミコロンを使用することです。Tim Berners-Lee がセミコロンについて語っています。これは、非常に長いパスを使用せずに、URL を意味のあるものにすることができるため、要件に適合する可能性があります。

于 2008-10-03T20:11:38.553 に答える