SaaSに加え、社内システムもREST APIで提供して再利用できると、開発効率はさらに大きく高まる。今話題の「マイクロサービス」は、そうした考えに基づくものだ。ただ、社内システムのAPI化を実現するには、さまざまな壁が立ちはだかる。壁とその乗り越え方を紹介しよう。
最近のSaaSは、数十種類のREST APIを備える。業務システムに組み込んで使うためだ。SaaSはもはや、パッケージソフトのように単独のアプリケーションというイメージではない。
こうしたAPIを使えば、サービス提供が一層迅速になる。開発負荷が下がる分、サービスで実装すべき機能やユーザー体験（UX）に力を注げる。ただ、SaaSのAPIの適用範囲は、汎用的な処理に限られる。通常、適用範囲外は、スクラッチ開発となる。
この点を改革するために、ユーザーがスクラッチ開発したシステムも、API経由で再利用できるようにする動きが始まっている。すなわち、既存の社内システムにREST APIを追加する動きだ。
REST APIの作成自体は、難しくはない。頻繁に利用されているビジネスロジックとデータは継続的な変更要求があり、機能分割とコンポーネント化が進んでいるケースが多い。
つまり、既存コンポーネントで実装済みの連携インタフェースを、REST/JSON形式のAPIに変換すればいい。認証、認可、シングルサインオンなどに対応させれば、他システムから利用しやすいREST APIになる。
具体的には、Jersey（JAX-RSの参照実装）やJava EE 7で標準化されたJSON用のバインディングAPIを使う方法がある。Javaで実装されたビジネスロジックとデータであれば、それを再利用して容易にREST/JSON形式のREST APIを作成できる。
マイクロサービスも視野に
社内システムにREST APIを活用するには「マイクロサービス」の考え方が必要になる。巨大で複雑なシステムを、独立した「サービス」の組み合わせで構成する考え方だ。
このサービスは、ドメイン（業務の単位）ごとにコンポーネント化され、分割統治される。米Netflixや米Amazonといった大手ネット企業を中心に取り組みが進んでいる。
サービス同士はシンプルなREST APIで通信する。あるサービスから別のサービスを見ると、複雑な機構は隠ぺい（カプセル化）されている。サービスの独立性は高く、開発言語やリリースサイクルが異なってもいい。SaaSもシステムを構成する一つのサービスと見なせる。
マイクロサービスのアーキテクチャーを採用しておくと、ユーザーの要求が変わった際に手早く対応できる。システム全体に影響を与えず、部分的に機能を拡張したり変更したりといったITサービス運営をしやすい。