16

RESTful API を設計しているときに、「同じオブジェクト」の異なるバージョンにアクセスする方法の問題に遭遇しました。ページ オブジェクトが一意のキーによって識別され、GET /api/page/pagekey によってアクセスされるとします。PUT /api/page/pagekey と本文に適切なドキュメントを送信することで更新できます。

これで、私たちのシステムはページの古いバージョンを追跡し、API 経由でもアクセスしたいと考えています。ドキュメントの古いバージョンがバージョン 1 であると仮定します。ページのこの特定のバージョンにアクセスする API を設計するには、少なくとも 2 つの方法があるようです。

  1. GET /api/ページ/ページキー/1
  2. GET /api/page/pagekey?version=1

最初のバリアントは、特定のバージョンを独自のリソースとしてレンダリングします。2 番目のバリアントは、既存のリソースにオプションのバージョン コンテキストを与えます。

  • バリアント (1) または (2) はより良い解決策ですか? またはそれを行うためのさらに良い方法はありますか？
  • バリアント (1) では、存在しないバージョン番号 (/api/page/pagekey/7 など) を要求すると、HTTP 404 Not Found がトリガーされる可能性がありますが、これは非常に便利です。バージョン パラメータなしで HTTP 200 Ok 応答を返す、既存のリソースのコンテキスト「バージョン」のみを変更するバリアント (2) を考慮すると、これも有効なステータス応答でしょうか?
4

2 に答える 2

9

各リソース URL は、そのリソースを識別するためのパーマリンクにする必要があります。 

GET /api/page/{id}/{rev}

これは確かに、リソースの特定のバージョンへのパーマリンクです。それで、それで結構です。ただし、パーマリンクのコンテンツが常に同じである必要はないことに注意してください。

GET /api/page/{id}

それは問題なく、時間の経過とともに内容を変更する最新のリビジョンを返します。さらに拡張するために、次のような一時的なリソースを使用して RESTful にすることもできます。

GET /api/page/latest

ただし、/api/page/{id}?version={rev}これも機能し、RESTful の概念を壊すことはありません。

/{id}/{rev}アドレス可能なURLでそのリソースを具体的に識別し、それをパラメーターにするよりも少し正確に感じるので、少し純粋だと思います。その理由は、params がコンテンツを取得する方法の修飾子である必要があり、取得している個別のリソースを必ずしも変更する必要がないためです。あなたの場合、各バージョンは異なるため、リソースを明確に扱う方が適切と思われます。しかし、それでも RESTful な URL の規則や概念に違反するものではなく、10 人に尋ねた場合、別の答えが得られるかもしれません :)

いずれにせよ、一時的なリソース/api/page/{id}が最新のリビジョンを返すことを確認する必要があります。

于 2012-10-04T23:40:27.147 に答える
0

ほぼ定義上、REST には「同じオブジェクト」という概念はありません。プロトコルでこれが必要な場合は、何らかの「識別子」が必要です。それと同じくらい簡単です;）

URL パラメーターは、1 つの明白な方法です。"/1" または "?version=1" は確かに 2 つの適切な代替手段です。どちらを選択するかは、単なる好みの問題です (また、どれだけの "その他のもの" が必要かという問題もあります)。

いずれにしても、「バージョンが見つかりません」のようなエラーに対処し、適切に回復する必要があります。

私見では...

于 2012-10-04T23:35:09.730 に答える