13

RESTful API の URI 設計に関する方向性を探しています。ネストされたリンクされたリソースをいくつか用意する予定で、現在、次の投稿のような URI を設計しています:階層的な RESTful URL の設計

次の例は私が構築しているものではありませんが、私の状況をよく表していると思います。(ショーは 1 つのネットワークにのみ属することができると仮定します)。

/networks [GET,POST]
/networks/{network_id} [GET,PUT]
/networks/{network_id}/shows [GET,POST]
/networks/{network_id}/shows/{show_id} [GET,PUT]
/networks/{network_id}/shows/{show_id}/episodes [GET,POST]
/networks/{network_id}/shows/{show_id}/episodes/{episode_id} [GET,PUT]

私の状況は、関連付けによってさらに 2 レベル進みますが、すべての関連付けは 1 対多です。次のようなものに切り替えることを検討しています。

/networks [GET,POST]
/networks/{network_id} [GET,PUT]
/networks/{network_id}/shows [GET,POST]

/shows [GET]
/shows/{id} [GET,PUT]
/shows/{id}/episodes [GET,POST]

/episodes [GET]
/episodes/{id} [GET,PUT]

私の質問は次のとおりです。

  1. 2 番目の例は有効な REST 設計ですか?
  2. 両方のパスの実装を検討する必要がありますか?
4

6 に答える 6

6

2番目の例は私にはうまく見えます。URL はリソースを説明しており、正しい HTTP 動詞が使用されています。

複数の URL が同じリソースを指していても、それが理にかなっていればまったく問題ありません。しかし、もっと重要なことは、<link />番組をネットワークに、エピソードを番組に接続する要素がリソースに含まれていることを確認することです。

于 2012-10-23T20:51:33.540 に答える
3

ここでの本当の質問: 2 番目の例は URI 標準を満たしていますか? URI標準は、パスには階層部分が含まれ、クエリには非階層部分が含まれていると述べていますが、afaik. あなたの状況でURI構造を設計する方法については何も教えていません。REST 統一インターフェース制約には HATEOAS セクションがあります。これは、状況に応じて、上位および下位レベルのリソースを指すリンクを送り返す必要があることを意味します。これらのリンクには、クライアントが処理できるメタデータで注釈を付ける必要があります。これにより、リンクの内容がわかります。したがって、実際にはURI構造はあまり重要ではありません...

GET /shows/123

{
    "label": "The actual show",
    "_embedded": {
        "episodes": [
            {
                "label":  "The first episode of the actual show",
                "_embedded": {
                    "associations": [
                        //...
                    ]
                },
                "_links": {
                    "self": {
                        "label": "Link to the first episode of the actual show",
                        "href": "/episodes/12345"
                    },
                    "first": {
                        "href": "/episodes/12345"
                    },
                    "duplicate": {
                        "href": "/networks/3/shows/123/episodes/12345"
                    },
                    "up": {
                        "label": "Link to the actual show",
                        "href": "/shows/123"
                    },
                    "next": {
                        "label": "Link to the next episode of the actual show"
                        "href": "/episodes/12346"
                    },
                    "previous": null,
                    "last": {
                        "href": "/episodes/12350"
                    }
                }
            }//,
            //...
        ]
    },
    "_links": {
        "self": {
            "label": "Link to the actual show",
            "href": "/shows/123"
        },
        "duplicate": {
            "href": "/networks/3/shows/123"
        },
        "up": {
            "label": "Link to the actual network",
            "href": "/networks/3"
        },
        "collection": {
            "label": "Link to the network tree",
            "href": "/networks"
        },
        "next": {
            "label": "Link to the next show in the actual network",
            "href": "/shows/124"
        },
        "previous": {
            "label": "Link to the previous show in the actual network",
            "href": "/shows/122"
        }
    }
}

現在、これは IANA リンク関係を使用した HAL+JSON の非常にベータ版ですが、JSON-LD を RDF ボキャブラリ (例: schema.org+hydra) で使用することもできます。この例は単に階層 (上、最初、次、前、最後、コレクション、アイテムなど) に関するものですが、どのリンクがネットワークを指すか、どのリンクがショーを指すか、どのリンクがどのリンクを指すかなど、さらにメタデータを追加する必要があります。エピソードなど...そのため、クライアントはメタデータからコンテンツが何であるかを知ることができます。たとえば、リンクを使用して自動的にナビゲートできます。これがRESTの仕組みです。したがって、クライアントにとって URI 構造は実際には重要ではありません。(応答をよりコンパクトにしたい場合は、コンパクト URI と URI テンプレートも使用できます。)

于 2015-01-09T15:30:59.020 に答える
1

次の階層で1対多の関係があることを考慮してください。

network --> shows --> episodes

2番目の設計では、サーバー側に要求を処理するための十分な情報が提供されていないと思います。たとえば、次のデータがある場合：

Network id  show_id episode_id
    1         1        1
    1         2        1
    1         1        2

冗長な最初の設計は、データをフェッチするための十分な情報をHTTPリクエストで提供します。/networks/1/shows/1/episodes/1

それどころか、2番目の設計は次のようになります。

/episodes/1

2番目の設計では、サーバー側がデータから行1と行2のどちらを意味しているかを知る方法はありません。

あなたの質問に答えるには：

  1. IMHOの2番目のデザインは、例として有効なRESTデザインではない可能性があります。回避策は、クエリパラメータを渡すことです。

  2. デザイン1は自給自足だと思います

更新：上記の私の答えを無視してください

  1. 2番目のデザインはあなたの例に有効なRESTデザインです
  2. デザイン2だけでも十分です

さらに：

/networks
/networks/{id}

/shows
/shows/{id}

/episodes
/episodes/{id}

十分な数のRESTURLである必要があります

つまり、次のURLは冗長になります。

/networks/{network_id} [GET,PUT]
/networks/{network_id}/shows [GET,POST]

/shows/{id}/episodes [GET,POST]
于 2012-10-23T21:03:00.310 に答える
1

URIは「名前を付けることができる任意の情報」です

あなたの質問はドメイン関連の質問であり、URI で名前を付けているリソースについて知っている人だけが実際に答えることができます。

ドメインについて推測しようとしているときに頭に浮かぶ質問は、「ショー」は本当に「ネットワーク」に依存しているのかということです。

ドメイン内のネットワークとは何ですか? 番組とネットワークの関係とは？単に番組を放送した人ですか？それとも生産情報と関係がありますか？

あなたの例2の方がはるかに適していると思います。

于 2012-10-23T21:17:37.937 に答える
0

REST API の URL はできるだけシンプルに保つ必要があると思います。

例: https://www.yoursite.com/api/xml/1.0/

ここでは、バージョン 1.0 の XML API の例を取り上げています。今後の更新では、API のバージョンを使用することを忘れないでください。

クライアントから依頼されたメソッドを確認できます。

e.g. tag

<method>getEpisodes</method>
于 2012-10-23T21:21:07.810 に答える