はじめに
API Firstアーキテクチャは、APIユーザーがアプリケーションのメインユーザーであるアーキテクチャです。 これは、このAPIが最高の優先順位を持ち、MVCパラダイムの別のビューではないことを意味します。 主な違いは、最初のAPIには完全で、適応性があり、十分に文書化されたAPIが必要なことです。 これは、ターゲット設定において特に重要です。モバイルプラットフォーム（アプリケーションはAPIを使用）、リセラー（プレゼンテーションレイヤーはAPIを使用）、および統合性は高いが接続性が低いマルチ製品環境。
MVCでのコードの再利用
MVCアーキテクチャは長い間人気があります。 2004年、Ruby on Railsのリリースにより人気が急速に高まっています。 MVCパラダイムにより、ユーザーがフロントエンドを使用し、従業員がバックエンドを使用するフロントエンド/バックエンドアプリケーション（CMSの形式）である場合、既存のコードを最も効果的に使用できます。 この場合、フロントエンドとバックエンドに同じソフトウェアスタックを選択し、これらのアプリケーションを可能な限り同様にする必要があります。 MVC戦略が正しく適用されると、アプリケーションの多くの部分でコードを再利用できます。 たとえば、DBAL / ORM、ビジネスロジック、プレゼンテーション、およびAAA（認証、承認、アカウンティング）など、特にAAAでは、従業員はクライアントと同じログインフォームを使用でき、両方のフォームに共通のコードがあります。 。
MVCのモバイルビュー
2007年に、AppleはiPhoneを導入し、Webアプリケーション（およびサイト）を小さな画面に正しく表示する必要性が急速に高まっています。 MVCアプリケーションは、小さな画面への適応に最適です。 必要なのは、スマートフォンまたはタブレットで表示するための個別のまたは変更されたビューのセットです。 モバイルおよびデスクトップデバイス用の一連のビューを作成する戦略は、「モバイルファースト」と呼ばれます。 これは、リーダーシップと意思決定を必要とする最も費用対効果の高い急進的なアプローチです。 すべてのソフトウェアは、すべての表現の洗練などの劇的な変化を必要とします。 これに代わる方法として、モバイルデバイス用とデスクトップ用の2つのビューセットのサポートがあります。 これらのビューは、多くの場合「m」サブドメインでホストされます。 これは、シンプルで透過的なアプローチです。
APIをMVCに追加する
アプリケーション開発の分野では、誰もがHTML5対Nativeについて議論しています。 ここでダニーブラウンを引用します。
今日、モバイルアプリケーションを作成する企業は、ネイティブアプリケーションまたはHTML5アプリケーションを作成することを選択する必要があります。 どちらのオプションにも長所と短所がありますが、間違った選択には費用がかかる可能性があります。 -ダニー・ブラウン
ネイティブアプリケーションを選択するには、完全で応答性が高く、十分に文書化されたAPIを作成する必要がありますが、HTML5を選択するには、アプリケーションのすべてのビューを変更する必要があります。 いずれかのオプションを支持する多くの議論があり、常に最良のものとそうでないものを決定することは状況に依存します。 ただし、常に失敗するアプローチが1つあります。APIをMVCの表現として作成することです。 なぜ失敗なのか、なぜ多くの人がそれを使用するのかを説明しましょう。
通常、サーバーがMVCパラダイムを使用する場合、ページの読み込み時間は200ミリ秒です。 サーバー機能：データベースの抽象化、ビジネスロジック、プレゼンテーション。 それが「シックサーバー」とも呼ばれる理由です。 First Server APIはプレゼンテーションの責任を負いません;リクエストに対するビジネスロジックが少ないため、「シンサーバー」と呼ばれます。 優れたAPIは、通常20ミリ秒に達する実行速度に対して高度に最適化されています。 つまり モバイルデバイスのページの読み込み中に最大10のAPI呼び出しを行うことができます（300ミリ秒など）。
これまで、誰かがMVCを選択してAPIが必要になった場合、最も簡単なことは、JSONを返すビューをいくつか追加して、それを「RESTful API」と呼ぶことです。 そして、あなたがしなければならないのは、いくつかのドキュメントを書くことであり、あなたの上司は幸せになります。 実際、このようなAPIはスケーラブルではなく、非常に遅いため、実際の使用にはまったく適していません。 これは、APIが長い間使用されており、後戻りできない場合に本当に感じられます。
TwitterとAPIが最初
2010年、Twitterは「API First」戦略を発表しました。 彼らは、モバイルアプリケーションと同様のアーキテクチャでJavaScript Webアプリケーションを作成し、Javascriptアーキテクチャと呼びました。 これにより、独自のAPIを完全に使用できました。 以前は、APIはWebアプリケーションへの追加でしたが、現在では他のすべての製品の開発の基礎になっています。 Twitter APIは、RESTful JSON APIを使用してJavaScriptプログラマーに最適な統合を提供することに焦点を当てています。 ただし、従来のページもサポートしています。
JavaScriptを使用せずにクローラーとユーザーをサポートするには、サーバーとクライアントの両方で実行されるレンダリングシステムが必要です。 -ツイッター
従来のページに「API First」戦略を並行して使用するこのアプローチを、「ハイブリッド」と呼びます。 下の図では、さまざまなアプローチをリストしようとしました。
おわりに
コードの最適な使用はコストを削減しますが、これは、従う強力なアーキテクチャ戦略がある場合にのみ達成できます。 First APIアーキテクチャに一致するコードのリファクタリングは、直接利益をもたらさないでしょう。 その後の変更のコストを削減することは間違いありませんが、そのような決定を下すために必要な信頼のレベルを得るのはそれほど簡単ではありません。
読み物
これはFirst Architecture APIに関する最初の記事ではありません。 さらに学習することに興味がある場合は、以下に示す資料（英語の資料）に精通することをお勧めします。
- 2009- API First Design、Cas Thomas （ブログ）
- 2011- 「API-First Development」、David Dossot （ブログ）
- 2011- Nikko Botistaによる「API中心のWebアプリケーションの作成」 （トレーニング）
- 2012- 「API First」、Mark O'Neill （ブログ）
- 2012- 「HerokuプラットフォームでのAPIファースト製品開発」 、do.com（長いビデオ）
- 2012- 「APIファーストデザインアプローチ」Ben Brignell （ブログ）
- 2012- APIs First、Amish Jani （ブログ）
- 2013- 「www.api-first.com」、Fiona and Evan （ウェブサイト）
- 2013- Ben Ramseyによる「API First（PHP Tek 2013）」 （プレゼンテーションスライド）
2013年11月26日にLeaseWebで開催したプレゼンテーションのトピック「API First」について11枚のスライドを選択しました。