2016-12-28 6 views
1

私はURIデザインのベストプラクティスのための様々なリソースを研究しました。ほとんどすべての著者やブロガーは、RESTFul API URIは、このように見える必要があると言っています。REST API URIを使用してリソースIDを渡す理由は何ですか?

/* List all users in account 2 where user id is 1 */ 

`/users/1/accounts/2/users` [GET] 

上記のapi呼び出し元は、リクエストごとに2つ以上のIDを渡す必要があります。

私のシナリオはかなり異なっています。

APIサーバーの前にはリソースマネージャー(RM)があり、すべてのリクエストが上記のサンプルAPIにアクセスするために有効なtokenで認証のためにRMを通過する必要があります。 注:[トークンはヘッダーを介して送信]

リクエストが承認されると、RMはインターセプタを介してAPIサーバーにユーザー情報(user_id、account_idなど)を提供します。

質問私のAPIサーバーは既にuser_idと彼のaccount_idを認識していますが、API URIでこれらの情報を取得する必要があります。

私は、次のようなデザインを試してみました:

1. /users/accounts/users 
2. /accounts/users 
3. /users 

このシナリオに最適な設計とは何ですか?私は2週間を過ごしましたが、これはエンタープライズAPIの設計であるため決定できませんでした。一度設計されたものは変わらないでしょう。

+0

フェデレーションを後で追加したり、マルチアカウント認証を追加したり、グローバル管理APIを追加したりする場合は、すべてをURIに入れます。また、キャッシングの目的で使用します。通話の内容がすべての視聴者と異なることを明確にする。 – jessehouwing

答えて

2

最後に与えた理由から、あなたのAPIは非常にになります。使い慣れていれば、変更するのは難しいかもしれません。一方、実装になります。認証/認可の仕組みが変わる可能性があります。あなたの企業は、がこのような方法でIDの周りを回るのモデルに移動することを望むかもしれません。そして、古い挙動に依存するすべての単一のAPIを再設計しなければならないことは確かにありません。

URIのURIに関連するリソースを識別するための十分な情報を含む、1日の終わりには、ReSTの重要な部分です。 URIはすべてである必要があります。アドレス指定しているリソースをさらに識別するために、帯域外情報や実装の詳細には依存しません。

+0

はい意味があります。承認メカニズムが変更されると破損します。 – mumair

関連する問題