1

重複の可能性：
RESTURIのバージョン管理方法

私は現在RESTサービスを作成していますが、クライアントがリクエストを行うときにサービスのバージョンを指定する方法についていくつかのアイデアを知りたいと思います。

たとえば、RESTサーバーをバージョン2にアップグレードするときに、サービスのバージョン1を実装しているすべてのクライアントの呼び出しが中断されないようにします。

他の人がURLにバージョンを追加したり、ヘッダーのどこかにバージョンを指定したりするのを見てきました。

これを実装するための「最良の」方法はないかもしれませんが、このテーマについていくつか考えていただければ幸いです（それぞれの長所と短所など...）

ありがとう

4

2 に答える 2

4

別のルートでそれを行います：

 http://my.service.com/v1/user/1

 http://my.service.com/v2/user/1

バージョン間で変更がない場合は、v1 バージョンのリソースにサービスを提供するコントローラーにルートをマップするだけです。

確かに、これにより同じリソースに対して複数の URL が作成され、気まぐれな筋金入りの REST エバンジンリストは泣き始めるでしょうが、この方法により、あなたとあなたのユーザーの管理が容易になります。私は、ユーザーがリクエストヘッダーを使用して、バージョン管理を処理するためにX-Pathなどを気にしないコンテンツタイプなどを設定することさえできないことを発見しました....

リソースの重複の問題を本当に回避したい場合は、バージョンのような get パラメータを渡すことができます。

 http://my.service.com/user/1?version=1

バージョンがない場合は、デフォルトで何でも構いません。これは実際には完全に REST の独断的ですが、API ユーザーに多くの負担をかけると思います。

ユーザーまたは API キーをバージョンにマップする方法があれば、ある種のユーザー ルックアップ テーブルを使用してバージョン間をルーティングできますが、これはかなりのオーバーヘッドです。

于 2012-10-11T20:38:49.637 に答える
0

Accept/Content-Type ヘッダーによるバージョン管理をお勧めします。リソース自体に大きな構造上の変更がない限り、URI はバージョン間で変更されるべきではありません。ここに素晴らしい説明があります: API バージョニングのベストプラクティス?

于 2012-10-12T03:26:16.320 に答える