11

http://example.com/v1/SomeResourceにデプロイされた RESTful Web サービスがあります。ある日、新しいプロトコル バージョン (下位互換性がない) がhttp://example.com/v2/SomeResourceにデプロイされます。クライアントから見ると、このアップグレードは 2 つの HTTP リクエストの間の任意の時点で発生する可能性があります。

サーバーは、v1 呼び出しをサポートしなくなり、クライアントが v2 にアップグレードされる予定であることをクライアントにどのように示しますか? 使用できる適切な応答コードはありますか?

クライアントに次の情報を提供したいと思います。

  1. 互換性のないアップグレードが行われました。プロトコルがまったく異なる可能性があるため、クライアントが新しいサービスを使用する方法はありません。
  2. 新しいクライアント ソフトウェアの URL。
  3. アップグレードする必要があることをユーザーに説明するメッセージ。
4

4 に答える 4

10

ピーター・ウィリアムズの次の記事をお勧めします

于 2009-03-26T12:55:05.290 に答える
8

ベスト プラクティス:

おそらく、URL からバージョン管理を除外し、新しいリソースを古いものと後方互換性を持たせる方がよいでしょう。

下位互換性:

URL に v1 を保持する必要があり、v2 URL を作成している場合は、両方の形式をサポートするか、古い v1 を廃止するかを決定する必要があります。古い v1 を廃止することを決定した場合は、v1 URL を要求しているすべての人に 303 または 401 を返すことをお勧めします。

古い URL の廃止:

303 See Other を使用することをお勧めします。または、関連するリダイレクトがない場合は、410 Gone を使用します。

ソース

303 その他を見る

リクエストへのレスポンスは別の URI で見つけることができ、そのリソースで GET メソッドを使用して取得する必要があります。このメソッドは主に、POST でアクティブ化されたスクリプトの出力がユーザー エージェントを選択したリソースにリダイレクトできるようにするために存在します。新しい URI は、最初に要求されたリソースの代替参照ではありません。303 応答はキャッシュしてはなりませんが、2 番目の (リダイレクトされた) 要求に対する応答はキャッシュ可能かもしれません。

応答の Location フィールドで別の URI を指定する必要があります (SHOULD)。リクエスト メソッドが HEAD でない限り、レスポンスのエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートを含める必要があります。

注: 多くの HTTP/1.1 以前のユーザー エージェントは 303 ステータスを理解していません。このようなクライアントとの相互運用性が懸念される場合は、代わりに 302 ステータス コードを使用できます。これは、ほとんどのユーザー エージェントが 303 についてここで説明されているように 302 応答に反応するためです。

すべてを文書化します。

懸念すべき主なことは、返品することを選択したものであり、それをドキュメントに記録するだけです. サービスをどのように機能させたいかを決めることができます。それを利用したい人はドキュメントに従ってください。

于 2008-11-10T18:15:12.727 に答える
4

そもそもやるべきではないと思いますが、おそらく手遅れです。

リソースが変更されたり、サービスの実装が変更されたりしても、リンクが同じままになるように、URI も静的にする必要があります。これにより、ブックマークが可能になります。また、URI にエンコードされたリソース間の関係が、それらが格納されている場所で表現される方法とは無関係であることも重要です。

RESTful Web サービス: 基本の記事から。

于 2008-11-10T20:39:58.970 に答える
0

代わりに 301 (301 Moved Permanently) の使用をお勧めします。理由を読んでください。

お役に立てば幸いです, ブルーノ・フィゲイレド

于 2008-11-10T18:27:26.197 に答える