ruby-on-rails - RESTful アーキテクチャの限界

Question

私は、人々がどの程度アプリケーションを RESTful に保っているのか疑問に思っています。物事は非常に簡単に壊れてしまうように私には思えます。その時点で、私がキャリアを始めたばかりの頃、哲学的アーキテクチャーのすべてを理解していたシニア プログラマーがかつて私に言ったことを実行する必要があります。

具体的な例として、Rails アプリでカスタム認証を実装しており、標準の「パスワード リマインダー」フォームがあります。ユーザー オブジェクトを更新しているため、REST の観点からプロセスの最後に行うことは、ユーザー オブジェクトに対する PUT です。しかし、ユーザーを更新する方法が複数あることを無視しても ( How to do REST-ful updates?を参照)、最初はどのユーザーを更新しているのかわかりません。確認メールを送信し、ユーザー ID + セキュア キーを使用してリンクをたどります。したがって、ユーザーの更新を最終的にトリガーするのは単純なリンクです (恐ろしい!) -- そうしないと、RESTful にするために別のボタンでユーザーを悩ませる必要があります。

これは私の質問を促した例の 1 つにすぎませんが、自明ではないアプリでは、そのようなケースが数十件あるはずです。

では、技術的なプログラマーが必要に応じて無視する一般的なガイドラインとして、RESTful アーキテクチャーをほとんど使用しているのでしょうか? 私が文献から得た印象はそれとはかなり異なっています - したがって、あなたが例外をどのように扱ってきたかについての質問です。ありがとう。

(実際、この場合の最終結果は、新しいパスワード/確認を伴う別のフォームになり、そのターゲットは PUT になる可能性があると思いますが、これは時々扱いにくいという私の一般的な感覚はまだ私にあります. 多分それは私のものです.自身の遅さ -- これは初めてではありません)。

Answer 1

私が働いている場所では、できる限り RESTful であるように努めることにしましたが、REST ガイドラインにうまく適合しない場合 (関係者全員がこれに該当することに同意します) は、実際的であるつもりでもあります。発散する。そうは言っても、ほとんどのユースケースをやや RESTful にすることができると思います。

ユーザーIDが分からない場合はこんな感じでしょうか。id を電子メール アドレスとするパスワード変更トークンのコレクション:

GET /changepasswordtoken/{userEmail}

または、API のクライアントがユーザー ID を知っている場合、これはおそらくより良いでしょう:

GET /user/{userId}/changepasswordtoken

GETユーザーのパスワード トークンの変更を求めています。これが一般向けの API である場合、明らかに応答ペイロードでこれを返すことはありませんが、ペイロードは「メールに送信されたパスワードを変更してください」などのメッセージを返す可能性があります。

次に、パスワード変更トークンをクエリ文字列パラメーターとして使用して、パスワードPUTまたはユーザーを更新します。PATCH

PUT /user/{userId}?changepasswordtoken=xyz

{
     "password": "new password"
}

Answer 2

http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_4から:

REST は、全体として適用されると、コンポーネントの相互作用のスケーラビリティ、インターフェイスの汎用性、コンポーネントの独立した展開、および中間コンポーネントを強調して、相互作用の待ち時間を短縮し、セキュリティを強化し、レガシー システムをカプセル化する一連のアーキテクチャ上の制約を提供します。

代わりに、アクターとリソースの難読化、ポイント ツー ポイントの 1 回限りの対話、レガシー システム (HTML メールなど) の全面的な採用と公開を強調するアーキテクチャ スタイルが必要な場合は、RESTful である必要はありません。 . あなたの基準に合った建築様式を見つけてください（または発明してください）。REST に魔法はありません。これは、多くの問題領域でたまたま機能する一連の制約です。これは、それらのニーズに合わせて設計されているためです。異なるニーズがある場合、同じ制約を適用することは非生産的で愚かです。