3

RESTfulWebサービスの274ページのセクションを理解しようとしていますHTTP PUT。存在しないリソースに対して発行PUTすると、リソースが作成されます。PUT既存のリソースを移動させる場合、HTTP 301（永続的に移動）が新しい場所で返されます。古いURIへのリクエストは、HTTP 301、404、または410を返します。

私の質問は戻ることについてHTTP 301です。これは、リソースが古いURIの所有権を永久に保持することを意味しているようです。

検討：/companies/{companyName}/departments/{departmentName}

使用することの次の利点がわかりますHTTP 301：

  • 同時実行性：あるユーザーが会社の名前を変更し、別のユーザーが部門に移動している場合、そのユーザーは何も問題がなかったにもかかわらず、HTTP404を取得します。HTTP 3012番目のユーザーを新しいURIにシームレスにリダイレクトできます。
  • ブックマーク：人間とコンピューターの両方が、長期保存のためにURIをブックマークする必要があります。人間はディスカッションフォーラムにリンクを投稿します。コンピューターは、キャッシュの目的とユーザー設定にURIを使用します。

次の問題が発生しHTTP 301ます：

  • 長期的なリソースの進化をブロックします：その存続期間中、部門は、、およびAに名前が変更されます。数年後、誰かが部門を作成したいと考えており、によって作成できなくなっています。公平を期すために、これが発生する実際的な例は考えられないので、おそらく問題ではありません。BCDAD
  • APIバージョンはその使用を制限します：新しいAPIバージョンがリリースされ、古いバージョンが削除されると、ルートリソースでさえ時間とともに変化します。HTTP 301クライアントが古いリソースと同じ方法で新しいリソースにアクセスできない場合に戻るポイントは何ですか？

適切な行動方針は何ですか？URL階層を別の方法でモデル化する必要がありますか？行動/反応は異なるべきですか？

4

3 に答える 3

1
PUTによって既存のリソースが移動した場合、HTTP301が新しい場所で返されます。

技術的には、HTTPでリソースを移動することはできません。クライアントとしてリソースを操作している場合、実行していることは次のとおりです。

GET /oldurl
PUT /newurl
DELETE /oldurl

サーバーは、新しいURLが古いURLのリソースの新しい場所であることを認識せず、クライアントがユニバーサルHTTPメソッドを使用して確立できるリダイレクトによるURLの永続性の概念はありません。サービスが、たとえば特定のパラメーターを渡し、基本的に上記をバックグラウンドで実行するだけでなく、プロセスでリダイレクトを作成することによってアイテムを移動できるAPIを提供する場合、そのリダイレクトが新しい操作で上書きPUT可能かどうか、および使用するリダイレクトの種類。

投稿のタイトルの名前が変更されると、古い名前を追跡し、クライアントが古いアドレスを参照するときにHTTP301を返すことになっていると理解しています。

これはRESTとは何の関係もなく、CoolURIが変更されないことの現れです。RESTfulサービスでは、サービスのエントリポイントから到達可能なリソースまたはリソースのシーケンスを介して新しいURLにリンクするだけで十分です。

たとえば、HTMLWebサイトはREST実装の規範的な例です

サービスエントリポイント=/blog
/blogから/blog/
archiveへのリンク/blog/archiveから/blog/new-post-titleへのリンク

ブログサービスは、人間がWebブラウザを使用して利用するように設計されているため、後で再訪するためにURLをブックマークすることをお勧めします。これがリダイレクトの目的です。

マシンツーマシンAPIは、同様のことを行う必要があります。

サービスエントリポイント=
//「http：// myservice / rels/companies」のrelを持つ
/companiesへのリンク/companies「item」のrelを持つ/companies/new-company-nameへのリンク

マシンは場所をブックマークすることは想定されておらず、代わりにエントリポイントから毎回ナビゲートを開始することが想定されているため、古い会社名について言及する必要はありません。

于 2012-11-26T12:03:05.450 に答える
0

単純なを返し404ます。これは、要求されたURIに一致するものがないことを意味し、ドキュメントから、次のように指定します。

状態が一時的であるか永続的であるかは示されません。

このように、過去のある時点で存在していたものを置き換えるために新しいリソースを作成することは完全に有効です。

それ以外の場合、リソースの名前を変更してリソースを移動302する場合は、リソースが別の場所にあることを指定して、いつでもを返すことができます。置換が生成されるまで、このステータスを返すことができます。ユーザーは、リソースがまだ再配置されていることを確認するために、これらのヘッダーを引き続き使用する必要があります。

リダイレクトは時々変更される可能性があるため、クライアントは今後のリクエストに引き続きRequest-URIを使用する必要があります。

于 2012-11-26T04:47:34.887 に答える
0

私自身の質問に答える：

  1. HTTP 301永遠に保つことが問題を引き起こすような実際的な例は考えられません。
  2. リンクは、APIバージョン間で存続することを意図したものではありません。あるバージョンのリソースは、別のバージョンのリソースを参照しないでください（を使用している場合でもHTTP 301）。APIの変更の結果としてリソースのURIが変更された場合、古いAPIは古いURIを永久に使用し続ける必要があります。

更新： Willy Tarreauによると、べき等性は、アプリケーションが短期間リダイレクトすることだけを要求します。クライアントが要求の再試行を完了すると、リダイレクトは不要になります（少なくともべき等性のためではありません）。パーマリンクなどの機能をサポートするために、リダイレクトを長期間保持したい場合がありますが、仕様には強制されません。

于 2012-12-06T21:46:57.993 に答える