組織内にステートフルWebサービスが必要です。しかし、私がオンラインで読んだところはどこでも、ステートフルWebサービスを構築することは悪いプログラミングであると言っていますが、その理由は何も言われていません。何がそんなに悪いのかわからないと思います。また、Webサービスで状態を取得できるようにするための回避策を提供する理由もよくわかりません。
だから私の質問は、ステートフルWebサービスを使用するのはなぜ悪いプログラミングなのか、そしてなぜそれが許可されるのかということだと思います。
組織内にステートフルWebサービスが必要です。しかし、私がオンラインで読んだところはどこでも、ステートフルWebサービスを構築することは悪いプログラミングであると言っていますが、その理由は何も言われていません。何がそんなに悪いのかわからないと思います。また、Webサービスで状態を取得できるようにするための回避策を提供する理由もよくわかりません。
だから私の質問は、ステートフルWebサービスを使用するのはなぜ悪いプログラミングなのか、そしてなぜそれが許可されるのかということだと思います。
Web サービスの全体的な目的は、非常にスケーラブルな方法で 1 つのトランザクションで機能の一部を提供することです。これは、物事をシンプルかつアトミックに保つことを意味します。
操作を実行するために複数の呼び出しを行う必要がある場合、トランザクションがハングしたままになる可能性が高くなります。クライアントは戻ってきますか?彼らは終わりましたか?トランザクションはどのくらいの期間開いたままにする必要がありますか? 彼らは墜落しましたか?ロールバックはどのように処理する必要がありますか?
これらの質問に対する答えは、サービスの実行に必要なリソースに根本的な影響を与える可能性があります。これが、誰もが一度にすべてを行うことを推奨する理由です。
ここに私が考えることができるいくつかの理由があります:
状態を維持するためのコストは、サーバー側でのみ負担する必要があります。サービスの消費者はめったに Web ブラウザーではないため、Cookie はありません。これにより、サーバーのパフォーマンスが低下し、設計が複雑になります。
サービス コンシューマは、愚かなブラウザではなく、インテリジェントなプログラムです。そのため、プログラムは (ほとんどの場合) 独自の状態を維持します。つまり、サービスを提供すると、消費者は必要なデータを正確に要求します。サーバーで状態を維持することは時代遅れになり、不要になります。
トランザクション - クライアントはほとんどがインテリジェントであり、状態の変化をいつ通知するかを決定するため、サービスはシステムの懸案事項です。これは、状態を維持する場合、サービス呼び出し間でトランザクション操作を完了するまで待機する必要がある場合があることを意味します。そして、クライアントが次のサービス呼び出しを行うという保証はまったくありません。
たくさんの理由がありますが、これらは私が頭のてっぺんから考えることができるものです:)