「時期尚早の最適化」について聞いたことがありますか? 一般的に、アプリケーションを設計するときのパフォーマンスはあまり気にしません。読みやすく、保守が容易で、将来の拡張が容易で、一般的には将来も保証されるコードを作成するようにしてください (たとえば、REST から SOAP への切り替えは、必要以上に手間がかかるべきではありません。これは、当初考えていたよりも現実的なシナリオかもしれません。一瞬）。パフォーマンスが向上する可能性があるという理由だけで、または「優れた設計」のパフォーマンスが低い可能性があると考えているという理由だけで、悪い設計を採用するべきではありません。
正直なところ、1 秒間に何回の REST 呼び出しを行う予定ですか? また、1 つの REST 結果内に何百万個のオブジェクトがあるでしょうか? 可能な限り最高の設計を作成し、後でパフォーマンスのボトルネック (浪費されている CPU 時間、メモリが浪費されているなど) を見つけたら、それらのボトルネックを最適化して取り除きます。運が良ければ、最初からボトルネックはありません。あなたの主な関心事が、この地球上でこれまでに見たことのない最速のコードを作成することである場合、最初から Java を使用しないでしょう。おそらく、可能な限り最低レベルの C を使用し、最後のコードを絞り出す必要がある場合はインライン アセンブリを使用します。 CPU のパフォーマンスの低下。
したがって、REST API に基づいて設計をモデル化するのではなく、アプリケーションの残りの部分をコーディングするのが最も簡単な方法であると思う方法で設計をモデル化し、REST を自分の API に変換するインポーター/エクスポーターを作成します。 design と my design を REST に。その後、SOAP などの別のテクノロジに切り替える場合は、アプリケーション全体ではなく、インポーター/エクスポーターを書き直すだけで済みます。
ただし、例外もあります。個人的には、オブジェクト指向言語の日付オブジェクトは嫌いです。タイムスタンプは完全な日付表現のIMHOであり、操作が非常に簡単で（比較、オフセットの加算/減算など）、メモリオーバーヘッドが非常に低くなります（数値のみ、通常はプリミティブであり、メモリ割り当てでさえありません）必要）。したがって、日付オブジェクトが必要でない限り、この値を必要に応じて保存または表示できないため、タイムスタンプをタイムスタンプのままにし、将来SOAPに切り替えてタイムスタンプの代わりに日付を提供する場合は、それらをタイムスタンプに変換しますインポーターで、エクスポーターで日付に戻ります。しかし、これは私だけです。