RESTサーバー & サービス

多くの企業向けアプリケーションは今日、単一のクライアント以上を必要とします。インターフェース、ポータル、スケジューリング、統合、バックグラウンド処理、そして技術的な運用ロジックがそれに含まれます。だからこそ、REST-サーバーとサービスを後付けの付属物としてではなく、同一のアーキテクチャの一部として設計します。

サービス指向の構成が有効なケース

• 複数のクライアントが同じ業務ロジックにアクセスする必要がある場合
• バックグラウンドプロセスが特定のワークステーションに依存してはならない場合
• ポータル、デスクトップ、第三者システムが制御された形で同一のデータ基盤を利用する必要がある場合
• リリース、運用、技術的責任をスケール可能なまま維持する必要がある場合

REST-サーバーとサービスを同一の業務ロジックの一部として

多くの企業ではAPIやバックグラウンドサービスが遅れて、しかもプレッシャー下で作られることがあります。その場合、既存のデスクトップ資産に後からインターフェースを追加しても、業務ルールはクライアント内に残り続けることが多く、これがほぼ必然的に不整合を招きます：同じルールが複数存在し、障害の把握が難しくなり、運用が特定の個人のノウハウに依存してしまいます。

私たちは逆のアプローチを取ります。システムがポータル、統合、インポート、エクスポート、ライセンスチェック、あるいはバックグラウンド処理を必要とする場合、クライアント、REST-サーバー、サービス間の責任分担を早期に明確にする必要があります。どのロジックが業務上の中心か？どの操作を再現可能にする必要があるか？障害状況はどのように記録するか？後でモノリスに依存したままにならないよう、どのようにデータフローを拡張できるか？

とりわけDelphi-システムではこの点が重要です。多くの価値あるビジネスロジックが既存資産に既に含まれています。そこからREST-サーバーやLinux、Windowsのサービスを派生させる場合、単にソースコードをコピーするのではなく、共通の業務基盤をアプリケーションからきれいに切り出すべきです。そうして初めて、クライアントと同じ言語を話すAPIやサービスが生まれます。

企業が REST およびサービスで注視すべき点

最も重大な誤りは多くの場合技術的なものではなく構造的なものです。プロジェクトはAPIがあればアーキテクチャの問いは解決したと考えがちですが、実際にはそこからが出発点です。API、ポータル、デスクトップクライアント、サービスは同一のデータ基盤、同一のロール、同一の業務ルールを理解している必要があります。

この方針が定まっていれば拡張ははるかに安全に計画できます。ポータルは同一のサーバーロジックにアクセスでき、バックグラウンドサービスは制御された形で同じオブジェクトを処理でき、サードパーティ連携は業務的に明確な箇所に接続されたままになります。この観点から、私たちは マルチプラットフォームクライアント、サーバーロジック、データ保持を一体のシステムと見なし、ばらばらの単体部品とは見なしていません。

結局のところ、良いRESTおよびサービスのアーキテクチャは、どれだけモダンに聞こえるかではなく、後にどれだけ安定して運用できるかで判断されます。サポート事象が追跡可能で、障害経路が可視化され、新たな要件が旧コードへの特別対応で終わらないなら、そこに真の技術的価値があります。

どのような兆候があれば REST とサービスのアーキテクチャ的な準備が必要かが分かるか

複数のクライアント、統合、あるいはバックグラウンドプロセスが同じルールを必要とする時点で、単なるAPIの発想はシステム設計の問題になります。そこで後に安定が得られるか継続的な摩擦が生じるかが決まります。

最初のアーキテクチャ調査が REST とサービスにもたらすべきもの

最大の効果は多くの場合フレームワーク自体ではなく、クライアント、サーバ、バックグラウンドプロセス間での責務の明確な分配にあります。

• 業務上中核に残すべきロジックと、サービス側で扱うべき領域の分類
• ロール、データ経路、ロギング、および技術的な稼働状態に関する視点
• 無秩序な並行実装を生まない、API、バックグラウンドジョブ、統合のための初期導入ルート

FAQ: RESTサーバーとサービスについて

多くのシステムはAPIのアイデア自体で失敗するのではなく、サーバー側のロジックが後から既存のデスクトップ基盤に場当たり的に付け加えられることで失敗します。私たちはこれらの部分を意図的に一体として設計します。