既存システムがある中でのAPI開発の進め方

APIファーストはこれからの考え方として重要ですが、すでに稼働しているシステムの方がまだまだ多いのが実情です。その多くは5年以上動き続けているというものもあるでしょう。そうしたシステムをAPIに対応させようと思った時にはどう進めるのが良いでしょうか。

別アプリケーションサーバを立てる

まず既存システムに対して手を加えるのは危険性が高いと思われます。常日頃から手を加えている場合は良いのですが、1年以上手を加えずに動いているシステムに対して改めて新規機能を追加するのはリスキーです。多くの場合、余計な修正が入ってしまって既存ビジネスに悪影響を与えたり、システム全容の把握に時間を要します。アーキテクチャも今風でないことも多いでしょう。

そこでAPIは新しいアプリケーションサーバ、新しいアーキテクチャで作り始めましょう。大事なのはデータベースのスキーマはちゃんと把握することです。これが違うと既存システムとAPIで別な値が返ってくることになります。また、コードは真似しないとしても、何を入力必須とするかと言ったシステム要件は合わせる必要があります。

表示系から作る

いきなりRESTfulに作り込むのは時間もコストもかかりすぎます。まずGET系（一覧取得、検索、詳細表示）から作り始めましょう。この場合、データ操作が伴わないので既存業務に影響を与える可能性は低いと言えます。

次にデータの追加を作ります。データ追加は更新に比べるとデータが正しく入っているかの確認がしやすく、他のデータに与える影響は少ない場合が多いためです。ただしシステム要件によって異なります。

次に更新系、そして最後に削除でしょう。削除については物理削除を行う場合には特に注意が必要です。

APIゲートウェイを使ってみよう

APIゲートウェイと呼ばれるサービスが最近注目を集めています。APIゲートウェイは多くの機能がありますが、主な機能としては以下が挙げられます。

• 認証
• アクセス制御
• ルーティング
• キャッシュ

認証はOAuth2またはトークンベースの認証が与えられます。この辺りの仕組みを作り込むのは時間も工数もかかりますがAPIゲートウェイであればすぐに作れます。さらにそのトークンごとのアクセス制御もできます。1日、月ごとのアクセス総量制御であったり、一気にアクセスが高まった際にも役立ちます。

APIはシステムからアクセスされるため、通常のWebブラウザ操作ではあり得ないくらいのアクセスが一気に来る可能性があります。DDoS攻撃かと思ってしまうくらいのアクセスが来た場合、APIサーバが落ちてしまうと他の利用者に対して影響が出てしまいます。もちろん自社で作り込むこともできますが、トークンベースのアクセス制御はアプリケーションサーバ上に実装する必要があります。IPアドレスベースであればファイアウォールなどで制御できますが、利用元IPアドレスが一つとは限りませんので注意が必要です。

APIと既存システムを融合させるか否か

既存サービスとAPIサーバが同じアーキテクチャで実装されている場合、最終的には両者を統合できる可能性があります。それによってライブラリやロジックの共有が進めやすくなるでしょう。これはAPIがそれほど利用されておらず、統合しても十分に負荷に耐えられる場合に有効です。

ただし多くのケースで、既存システムに対してAPI機能を組み込んだ後で、再度分離しています。APIサーバと既存システムとでメンテナンススパンが異なったりすると、デプロイによる影響が少なからずあるためです。既存システムがすでに安定稼働している場合、API開発に伴う頻繁な再起動はよくありません。

また、APIサーバを別ドメインにしている場合はあえて統合するメリットは薄いと言えます。セキュリティ上の要件においても別ドメイン化しておくのはメリットがあります。将来的にAPI利用の規模増大によってAPIサーバの前にAPIゲートウェイを配備することもよくあります。そうした意味においてもAPIサーバは独立しておくのが良いでしょう。

API開発は既存のシステム開発の延長と捉えない方が良いでしょう。既存システムの中で作り始めると、多くの場合ずるずるとスケジュールが延長されてしまい、結果としていつまでも稼働できなくなります。それは既存システムは規模が大きく、全体を把握して改修を進めなければ問題が発生するためです。

別サーバで構築する場合はミニマムにはじめられます。ロジックは共有できなくなりますが、それでも仕様さえ決まっていれば正しく実装できるでしょう。