3
4

3 に答える 3

2

RESTful な観点からは、両方の表現を同じように処理してもまったく問題ないと思います。ダウンロードしたいバージョンがいくつかあるソフトウェアを考えてみましょう。最新のものは 3.8 です。したがって、最新バージョンを入手したい場合は、新しいバージョンが登場するまで両方GET /software/version/latest.zipで対処できます。GET /software/version/3.8.zipしたがって、2 つの異なるリンクが同じリソースを指しています。

私はページネーションがほとんど同じだと想像するのが好きです。最初のページには常に最新の記事があります。したがって、パラメータが指定されていない場合pageは、単純に 1 であることを示すことができます。

属性を使用したアプローチはrel、少し異なる方向に進んでいます。これは、重複コンテンツの問題をより適切に処理するために Google が作成したものであり、主に「メイン」ページとページネーション ページを区別するために使用されると考えられています。使用方法は次のとおりです。

//first page:
<link rel="next" href="http://www.foo.com/foo?page=2" />

//second page:
<link rel="prev" href="http://www.foo.com/foo?page=1" />
<link rel="next" href="http://www.foo.com/foo?page=3" />

//third and last page:
<link rel="prev" href="http://www.foo.com/foo?page=2" />

したがって、SEO の観点からは、これらの要素を使用することをお勧めします (Google も推奨しています)。また、REST のリソース指向の考え方やリソースのハイパーメディア表現とも完全に調和します。

303 See Otherあなたの提案の1つを選択すると、それが正しい方法だと思います。これは、この種の目的で使用することを意図しており、リソースを正規化するための良い方法です。多くの URI を介してそれらを利用できるようにすることができますが、表現には 1 つの「実際の」URI を使用します (異なるバージョンのソフトウェアのように)。

仕様によると、応答は次のようになります。

303 See Other
Location: http:www.foo.com/foo?page=1

<a href="http:www.foo.com/foo?page=1">http:www.foo.com/foo?page=1</a>

そのため、Location-header に「実際の」表現を提供し、本文には新しい URI にリンクするハイパーテキスト ドキュメントを含める必要があります。仕様によると、クライアントはLocation の値に GET リクエストを送信することが期待されていますが、そうする必要はありません。

//あなたのコメントへの回答として編集します（そうです、それを証明せずに何かを主張するのは本当に悪い習慣です:-)-私の悪い!):

Google は、 2011 年 9 月に公式ウェブマスター セントラル ブログrel="next"でとrel="prev"の属性を発表しました。タグに追加して (場合によってはタグの代わりに) 使用できます。rel="canonical"

これらのリンクの下で、説明されているそれらの違いを見つけることができます。

  • rel="next"およびrel="prev" link 要素は、「ページ分割されたシリーズのコンポーネント URL 間の関係を示すため」です。
  • rel="canonical"「好みのバージョンの URL を公に指定できるようにする」

そのため、それらの間にはわずかな違いがあります。したがって、問題を標準的な問題に分解できます。同じリソースを指す複数の URL があります (/fooそしてfoo?page=1、URL の優先バージョン ( ) がありますfoo?page=1)。したがって、RESTful アプローチにはいくつかのオプションがあります。

  • pageクエリに - パラメータが指定されていない場合は、処理時にデフォルト値 (1 など) を使用します。この特定のケースでは、悪い習慣として指摘されていても、デフォルト値を使用しても問題ないと思います。
  • 303 See Otherで応答し、 Locationヘッダーに優先 URL を指定します(上記のとおり)。3xx応答は、重複/正規のコンテンツを処理するための最良の (そしておそらく RESTful を意図した) 方法だと思います。
  • クライアントに - パラメータを強制的に提供させたい場合は、 400 Bad Requestで応答しますpage(zzzzBov の回答で説明されているように)。この応答にはLocationヘッダーのようなものがないことに注意してください (質問で想定されているように)。そのため、要求が失敗した理由の説明および/または正しい URL (指定されている場合) は、応答のエンティティ本体に移動する必要があります。また、仕様によると、この応答は、クライアントがor要求とともに不適切な/不正な表現 (URL ではなく!) を送信するときに一般的に使用されることに注意してください。そのため、これもクライアントにとって少し曖昧である可能性があることに注意してください。PUTPOST

個人的には、 405 Method Not Allowedで応答するという提案は良い考えではないと思います。仕様によると、許可されたメソッドをリストするAllowヘッダーを提供する必要があります。しかし、このリソースでどのようなメソッドを許可できるでしょうか? しか思いつかない。ただし、クライアントにもそれを許可したくない場合は、禁止されている理由を説明して403 Forbiddenで応答するか、禁止されている理由を伝えたくない場合は404 Not Foundで応答することもできます。だから、それも少しあいまいかもしれません（私の意見では）。POSTPOST

linkリソースの表現で解決されるのはハイパーメディアのみであるため、質問で提案するように、言及された -attributes で -elements を使用relすることは、本質的に「RESTful」ではありません。しかし、あなたの問題は（私が理解している限り）、特定のリクエストにどのように応答するか、どの表現を提供するかを決定したいということです。しかし、それでも完全に無意味というわけではありません:

SEO の問題全体を を使用することの副作用と考えることができますが、REST の特徴の 1 つである接続rel="next/prev/canonical"性 (リンクを持つことの品質として)も作成されることに注意してください ( Roy Fielding の論文を参照)。

RESTful Web サービスに飛び込みたい場合 (それだけの価値があります) 、Leonard Richardson と Sam Ruby によるRESTful Web Servicesという本を読むことをお勧めします。

于 2012-02-09T15:18:46.017 に答える
2

まず、REST は SOAP のような確立されたプロトコルではなく、言語がオブジェクト指向であると説明されているのと同様に、サービスを構造化する手段に過ぎないという事実から始めましょう。

そうは言っても、これを次のように処理することをお勧めします。

RESTful 呼び出しを関数宣言のように扱います。

GET /foo
foo()

一部の関数にはパラメーターが必要です。

GET /foo?start=??&count=??
foo(start, count)

デフォルトのパラメーターをサポートする言語もあれば、サポートしない言語もあります。パラメータをどのように処理するかを自分で決めることができます。

デフォルトのパラメーターでは、関数が次のように定義されていると想定できます。

foo(start = 0, count = 10)

への呼び出しGET /fooは実際には と同等ですがGET /foo?start=0&count=10、 への呼び出しGET /foo?start=100は と同等GET /foo?start=100&count=10です。

デフォルトのパラメーターが必要ない場合は、API のユーザーに明示的に設定するよう強制できstartますcount。

foo(start, count)

を呼び出すとステータス コードGET /fooが返さ400 Bad Requestれますが、 を呼び出すと、指定された範囲に含まれるコンテンツとともにステータス コードGET /foo?start=0&count=10が返されます。200 OK

どちらの場合でも、次のようなエラーの処理方法を決定する必要があります。

GET /foo?start=-10&count=99999999

パラメータに最大値と最小値がある場合、パラメータを正規化するか、単にエラーを返すかを決定する必要があります。前の例はステータス コードを返す場合がありますが、次の400 Bad Requestように変更するように制限することもできます。

GET /foo?start=0&count=1000

最終的には、アプリケーションのコンテキストで最も意味のあるものを決定するのはあなた次第です。

于 2012-02-09T15:08:45.890 に答える
0

場合によっては、クライアントのために何も暗黙的に管理しないと、オーバーレイの複雑なインターフェイスにつながる可能性があります。たとえば、消費者が技術的でない場合や、Web ページなどのインターフェイスの上に構築するつもりがない場合などです。このような場合は、200 が適切な場合もあります。

他の場合では、消費者が応答を正しく予測できるようにしたい場合や、単純な仕様が必要な場合があるため、暗黙的な管理は悪い考えであることに同意します。このような場合は、405、400、および 303 です。

それは文脈の問題です。

于 2012-02-10T14:29:41.947 に答える