11

CRUD アクションの場合、動詞は非常に単純です。

賛成票のようなアクションのみを実行するための適切な HTTP 動詞は何でしょうか?

たぶん、これはデータモデリングにもっと関係していますか? 賛成票はリソースですか、それとも単なる属性ですか? 私はそれについて確信が持てません。#upvoteモデルを呼び出してリソースを直接変更するとします。

たとえば、ここで SO に関する質問に賛成票を投じた場合、そのアクションにはどの動詞を使用するのが理想的ですか? リソースを部分的に変更していますPATCHが (?)、同時に、同時実行の問題が発生する可能性があるため、新しい値を指定したくないため、これはデータベースで管理するのが最適です。つまり、リソースに対してインクリメンタル アクションを実行するようにサーバーに要求します。それはでカバーされていPATCHますか？

私はそこで尋ねられた同様の質問を見たことがありますが、彼らのケースは、ジョブリクエストを作成されるオブジェクトとして見ることによる新しいリソースの作成を指していました. ここでも同じケースですか？

そのPATCH方法が本当に適切であるとすれば、それには何が含まれますか?

4

1 に答える 1

9

たぶん、これはデータモデリングにもっと関係していますか? 賛成票はリソースですか、それとも単なる属性ですか?

モデリングは実装に影響を与える

私たちは通常、現実世界から何かをモデル化していますが、表現の選択は、開発されたシステムの機能に深刻な影響を与えます。投票は 2 つの方法で実装できます。投票対象の属性として、またはそれ自体のエンティティとしてです。この選択は、必要な機能をどれだけ簡単に実装できるかに影響します。


2 つの可能な実装...


1.エンティティとしての投票

これを、投票者と投票対象との関係をモデル化したリソースでモデル化します。なんで？

投票の状態は次のとおりです。

  • 何が投票されていたのか
  • 誰が投票したか、
  • 彼らはいつ投票しましたか。
  • それは賛成票でしたか反対票でしたか（SOを例として挙げたので、ここにその可能性を含めます）

投票に関する興味深い動作を備えた、それ自体がリソースです

  • 正しい投票数を維持する
  • 複数の賛成票/反対票を防ぐ


REST で簡単にモデル化できます。

新しい投票を POST/PUT したり、以前の投票を削除したり、修飾された GET で投票を確認したりできます。

システムは、私が 1 回だけ投票することを保証することができます。これは、単純なカウンターが維持されている場合には簡単なことではありません。


2.属性としての投票

この実装では、投票をカウンターとしてモデル化します。この場合、私たちはしなければなりません

  1. 投票されているものの全体的な状態を取得する- クライアントとサーバー間のインターフェースを最大化する

  2. カウンターを更新する

  3. 更新された状態を元に戻します - おっと、その間に誰かがすでにリソースを更新しました!

サーバーには、「側で」いくつかの状態を管理せずに、同じ人からの複数の投票を処理する簡単な方法がありません。また、「失われた更新」の問題もあります。

物事はすぐに複雑になります。


最終アドバイス

何かをモデル化する方法の決定は、システムに何をさせる必要があるかによって決定されるべきです。

多くの場合、正しい決定はなく、努力と価値の間の最善の妥協点しかありません。

最も一般的なユースケースを最も簡単に実装できる設計を選択してください。一般的なことはすばやく簡単に実行できる必要があり、一般的でないことは可能である必要があります。


クリス

于 2012-03-16T11:11:05.603 に答える