0

私は開発者会議に出席し、講演者は次のURLのセットはRESTfulではないと主張しました。

/users/username/changepassword
/users/username/resetpassword

与えられた主な理由は、同じURLが異なるコンテキストで使用される可能性があり、これがHATEOASを意味のある方法で促進しなかったことです。その後、彼は、より実行可能なアプローチは次のURLを使用することであると主張し続けました。

/account/changepassword
/administration/server/users/username/resetpassword

講演者によると、この後者のアプローチでは、各ユースケースでURLごとに特別に調整された（html-）フォームを作成し、同じURLに投稿することができました。異なるコンテキストで使用される同じURLでこれ以上の問題はありません。

これらのURLセットはどちらもRESTfulではないと自発的に言います。これは、どちらもアクション（動詞）を中心としているためです。これは、例外的な場合（検索など）を除いて、実際にはリソースとしての資格がないためです。この設定はRPCに非常に似ているように感じます。

もっと名詞のような、きめ細かいものを提案しただろう

 //Change password
 PUT /users/username/account/password
 //Register reset
 POST /users/username/account/password/resets
 //Verify reset
 PUT /users/username/account/password/resets/0/verification_code

あなたの意見は何ですか？スピーカーはRESTfulにアプローチしているかどうか、または単にここに十分な情報がないのですか？

4

1 に答える 1

1

私は同意します。RESTfulインターフェースの全体的な考え方は（私が理解しているように）「リソース」へのアクセスを許可することです。したがって、これらのURLスキームはどちらも私にはあまり良くないようです。

RESTは決まったものではないと言っても、それは一連のルールというよりもガイドです。いくつかのことはそれにうまく適合しないので、HTTP動詞を使用するだけでできる限り近づく必要があります。

パスワードのリセットはリソースではありませんが、パスワードはリソースです。だから、私はパスワードリセット操作のためにこれらの線に沿って何かを言うでしょう...

GET /users/antonyscott/password
PUT /users/antonyscott/password

2番目の呼び出しでは、最初の呼び出しから派生した何らかの認証が必要であり、新しいパスワードを渡します。実際、これはリセットというよりも、パスワードを直接変更することです。リセット後（つまり、リセットを確認するために電子メールのリンクをたどる）の場合は、問題がないように見えます。

明らかに、APIの設計は反復的なプロセスであるため、試してみて、APIがどのように機能するかを確認してから、改良する必要があります。

于 2012-09-11T19:26:21.177 に答える