"id"と "event"を入力としてデータベースに保存し、もう一方は "id"、 "event"、 "thirdparty"を入力としてデータベースに保存するという2つのアクションがあります。プロセスは似ていますが、少し異なります。 "thirdparty"では、 "イベント"に関連する "thirdparty"のデータベースをチェックする必要はありません。私は、2つの類似のアクションを2つの別々のメソッドに2つのルートで入れたり、1つのプレーフレームワークにマージする必要がありますか？
質問は、どのパフォーマンスが最も良いですか？いくつかのスイッチングロジックを備えた1つのルート？または2つの別々のアクションを持つ2つのルート？
私はscala play 2.5.xとcassandraデータベースを使用しています。
さらに一般的には、ルートを増やす方が良いでしょうか？より少ない経路ではあるがより複雑な論理？
コードが同じ場合（スイッチは除きますが無視してください）、パフォーマンスは同じです。コードの重複を避け、一貫したエンドポイント・リストを持つように、コードとエンドポイントをどのように構造化したいかという問題がますます重要になります。
これは実際にアプリケーション固有のものなので、どちらかを提案するのは難しいです。両方とも、アプリケーションの構造に応じて正しいです。性能の面で
各リクエストは独立しているので、基本的に同じであり、唯一の違いは、第三者が呼び出されるべきか否かを確認するifあろう。
ベストプラクティスに関して、オプションの引数とスイッチロジックを持つ他のルートがある場合は、おそらくコード内の一貫性を維持するためにそのロジックを選択します。そうでない場合は、コードがあまりにも複雑にならない限り、一緒に意味のあるルートをグループ化する必要があります。コードが複雑になる場合は、とにかくグループ化してはならないという兆候です。
この場合、サードパーティに連絡するのは簡単なステップのように思えるので、私の直感は経路のみを使用することですが、決定するのはあなた次第です。どちらのオプションも正しいです。
私はそれがパフォーマンスの面で全く差をつけるかどうかについてもっと興味がありました。より多くのルートを持つ方がよいでしょうか？より少ない経路ではあるがより複雑な論理？ – yang
@yangコードが複雑すぎると、エンドポイントが多すぎることをしている可能性があり、リファクタリングする必要があるという兆候です。この場合、それは単純な余分なステップのように見えます。私はより多くの洞察で答えを更新しました – nmat