5

各ユーザーが todo のリストを所有する、非常に単純な todolist RESTful API を作成したいとします。ユーザーはすでに http BASIC または DIGEST で認証されています。

この時点では、URL スキームがどのように見えるべきかわかりません。それは次のようになります。

http://servername/todos/

サーバーは、http ヘッダーによって与えられた認証に従って、適切な todo をフィルタリングします。

または、代わりに URI にユーザー名を含める必要があります。

http://servername/users/username/todos/

一部の Web サイトでは、次のようにユーザー名をパラメーターとして渡すことさえ見てきました。

http://servername/todos?username=babsi

私が知る限り、3 つの選択肢はすべて、ユーザー名を常に受け​​取るためステートレスですが、ソースが異なるだけです。URIが適切なユーザーによってアクセスされていることを確認するために私が言えることから、とにかくhttpヘッダーを常にチェックする必要があります。では、REST での最適な URI 設計はどの方法だと思いますか? それとも、まったく別の方法で行うべきでしょうか?

4

3 に答える 3

2

以下を使用できます。

http://servername/todos/ GET list all todos
http://servername/users/ GET list all users
http://servername/users/{user_id}/ GET list an user
http://servername/users/{user_id}/todos/ GET list all todos for an user

ここでのポイントは、リソース間の関係をどのように設計したいかということだと思います.todoがユーザーのコンテキストに存在できる場合は、上記のような階層のようなアプローチを使用します. 原則として、私は通常これに従います：

パス変数を使用して階層をエンコードします: /parent/child

/parent/child1;child2 のように、パス変数に区切り文字を入れて、階層が存在しないことを示唆しないようにします。

クエリ変数を使用して、アルゴリズムへの入力を暗示します。たとえば、/search?q=jellyfish&start=20 です。

于 2013-05-29T15:18:36.497 に答える
2

URL にユーザー名を含めるかどうかは、URL 内のユーザー名が認証と一致しないリクエストを受け取ったときに何をしたいか (もしあれば) によって異なります。この状況でユーザーを再承認したい場合は、はい - URL にユーザー名を含めても問題ありません。それ以外の場合は、そのような必要がなければ、ヘッダーまたは他の認証スキームに含めるだけで問題ありません。

有効な要件のかなり一般的な例の 1 つは、他のユーザーになりすますことができるメイン ユーザー (またはそのようなユーザーのグループ) が必要な場合です。

于 2013-05-29T15:11:33.747 に答える