バックエンドをAPIとして記述する必要がありますか？
今日、私たちのMVCアプリケーションについて白熱した議論がありました。 MVC（ ASP.NET ）で記述されたWebサイトがあり、通常はビューで何かを実行するパターンに従います->コントローラをヒットします->コントローラがモデルを構築します（取得するマネージャを呼び出します）データ、コントローラーメソッド自体でモデルを構築します）->モデルが表示されます->リンスして繰り返します。
私たちのコードは結合が強すぎると彼は言った。たとえば、デスクトップアプリケーションも必要な場合、既存のコードを使用することはできません。
彼が言った解決策とベストプラクティスは、APIを構築してから、そのAPIの上にWebサイトを構築し、デスクトップアプリケーション、モバイルアプリなどを構築することは非常に簡単です。
これは、さまざまな理由で私には悪い考えのようです。
とにかく、私はこの実践について議論するかもしれないグーグルで何かを見つけることができないようです。誰もが賛否両論、なぜあなたがそうすべきか、なぜあなたがそうすべきでないか、またはさらに読むべきかについての情報を持っていますか？
悪い考えだと思ういくつかの理由：
APIからバックエンドを実行するのはあまりにも抽象的です。あなたはそれをあまりにも柔軟にしようとしています、それはそれを扱いにくい混乱にするでしょう。
MVCに組み込まれているすべてのものは、役割や認証など、役に立たないようです。たとえば、[Authorize]属性とセキュリティ。自分でロールバックする必要があります。
すべてのAPI呼び出しにはセキュリティ情報を添付する必要があり、トークンシステムなどを開発する必要があります。
プログラムで実行するすべての機能に対して、完全なAPI呼び出しを記述する必要があります。実装するほとんどすべてのメソッドは、APIから実行する必要があります。すべてのユーザーのGet/Update/Deleteに加えて、ユーザー名の更新、ユーザーのグループへの追加など、その他の操作ごとのバリアント。それぞれが個別のAPI呼び出しになります。
APIに関しては、インターフェースや抽象クラスなど、あらゆる種類のツールを失うことになります。 [〜＃〜] wcf [〜＃〜] のようなものは、インターフェースを非常に微妙にサポートしています。
ユーザーを作成するか、何らかのタスクを実行するメソッドがあります。 50人のユーザーを作成する場合は、50回呼び出すことができます。このメソッドをAPIとして実行することを決定した場合、ローカルWebサーバーは名前付きパイプがそれに接続でき、問題はありません。デスクトップクライアントもヒットする可能性がありますが、突然の大量のユーザー作成では、インターネット経由でAPIを50回ハンマー処理する必要があります。良くない。したがって、バルクメソッドを作成する必要がありますが、実際にはデスクトップクライアント用にそれを作成しているだけです。この方法では、最終的には、a）APIと統合する対象に基づいてAPIを変更する必要があり、直接統合するだけではなく、b）追加の関数を作成するために、さらに多くの作業を行う必要があります。
[〜＃〜] yagni [〜＃〜] 。たとえば、1つのWebアプリケーションと1つのWindowsアプリケーションなど、まったく同じように機能する2つのアプリケーションを作成することを特に計画していない限り、これは膨大な追加の開発作業です。
エンドツーエンドでステップ実行できない場合、デバッグははるかに困難です。
多くのやり取りが必要な独立した操作がたくさんあります。たとえば、一部のコードは現在のユーザーを取得し、ユーザーが管理者ロールにあることを確認し、ユーザーが所属する会社を取得し、他のメンバーのリストを取得し、それらをすべて送信します。 Eメール。それには多くのAPI呼び出し、または必要な特定のタスクをカスタマイズしたメソッドを記述する必要がありますが、そのビスポークメソッドの唯一の利点は速度ですが、欠点は柔軟性に欠けることです。
おそらくこれらの理由は、これらが私の頭の上にあります。
同じアプリケーションを2つ本当に必要としない限り、それだけの価値はないように思えます。このように作成されたASP.NETアプリケーションも見たことがありません。2つの個別のアプリケーション（APIとコード）を作成し、それらもバージョン管理する必要があります（ユーザーページが新しいフィールドを取得した場合、 d APIと使用するコードを同時に更新して、悪影響がないことを確認するか、堅牢性を維持するために多くの追加作業を行う必要があります。
編集：いくつかの素晴らしい応答、これが今何を意味するのかについての良い考えを本当に得始めています。では、私の質問を拡張して、このAPI構造に従うようにMVCアプリをどのように構成しますか？
たとえば、ユーザーに関する情報を表示するWebサイトがあるとします。 MVCでは、次のようになります。
ビュー-UserViewModelコントローラーを表示する（CS）HTMLページ-GetUser（）を呼び出して、GetUserメソッドを持つビューマネージャークラス（APIの一種）に渡すUserViewModelを作成します。
コントローラはGetUser（）を実行しますが、デスクトップアプリも必要です。つまり、ある種のAPIを介してGetUserを公開する必要があります。 TCP接続、WCF、またはRemotingのいずれかが必要な場合があります。また、永続的な接続は不安定なため、RESTfulになるモバイルアプリも必要です。
それでは、それぞれにAPIを記述します。GetUser（）メソッドがあり、コードがreturn new UserManager().GetUser()を実行するWCF Webサービスですか。そして、同じことをするMVC 4 Web APIメソッド？ MVCコントローラーメソッドで直接GetUserを呼び出し続けている間ですか？
または、3つすべて（web api REST service））で機能するソリューションを選択し、その上にすべてを構築して、3つすべてのアプリがAPI呼び出し（mvcのもの、ローカルマシンへ）を行うようにします。
そして、これは理論的に完璧なシナリオですか？特にRESTfulな方法で操作を実行できるように開発する必要がある場合は、この方法で開発するとオーバーヘッドが大きくなることがわかります。これの一部は返信でカバーされたと思います。
編集2：もっと読んだ後、私はそれを説明するかもしれないと思うコメントを以下に入れました。この質問は、ちょっとしたトリックの質問だと思います。バックエンドをAPIとして作成する場合、すべて（mvcアプリ、デスクトップアプリ、モバイルアプリ）が何かを実行するために呼び出す単一のWebサービスがあるべきだと私は混乱しました。
私が得た結論は、ビジネスロジックレイヤーが正しく分離されていることを確認することです。私のコードを見て、私はすでにこれを行っています-コントローラーはマネージャーでGetUser()を呼び出し、それからビューモデルを作成してビューでレンダリングします。つまり、ビジネスロジック層はAPIです。ただし、デスクトップアプリから呼び出す場合は、WCFサービスのようなものを記述して、呼び出しを容易にする必要があります。コードGetUser()を含むreturn MyBusinessLayer.GetUser()と呼ばれるWCFメソッドがあるだけでも十分です。したがって、APIはビジネスロジックであり、WCF/Web APIなどは、外部アプリケーションがそれを呼び出すためのコードのほんの一部です。
そのため、必要なものに応じてビジネスロジックレイヤーを異なるAPIでラップする必要があり、他のアプリに実行させる各操作に対してAPIメソッドを記述する必要があり、さらに認証を行う方法を整理しますが、大部分は同じです。ビジネスロジックを別のプロジェクト（クラスライブラリ）に貼り付ければ、おそらく問題はありません。
うまくいけば、この解釈は正しいです。それが生成したすべての議論/コメントをありがとう。
はい、そうすべきです。
それはあなたのバックエンドを再利用可能にするだけでなく、より多くのセキュリティとより良いデザインを可能にします。単一システムの一部としてバックエンドを作成する場合、拡張、置換、または拡張が決して容易ではないモノリシックデザインを作成しています。
これが現在人気のある分野の1つは Microservices です。バックエンドが多数の小さな（または大きな）サービスに分割され、それぞれがクライアントシステムが使用するAPIを提供します。アプリケーションで多くのサードパーティのデータソースを使用することを想像すると、すでにこれを行っている可能性があります。
もう1つの利点は、各サービスの構築と保守を別のチームに引き渡すことができ、製品を作成している他のチームに影響を与えない機能をサービスに追加できることです。彼らが完了してサービスをリリースしたときだけ、彼らはあなたがそれらを消費するためにあなたの製品に機能を追加し始める。これにより、開発がはるかにスムーズになります（全体的に遅くなる可能性がありますが、品質が向上し、理解しやすくなる傾向があります）。
編集：OK問題が発生しました。あなたはAPIをリモートライブラリと考えています。そうではありません。このサービスは、データ提供サービスのようなものと考えてください。サービスを呼び出してデータを取得し、そのデータに対してローカルで操作を実行します。ユーザーがログオンしているかどうかを確認するには、「GetUser」を呼び出してから、'logged on'値など。 （ [〜＃〜] ymmv [〜＃〜] その例ではもちろんです）。
一括ユーザー作成の例は、言い訳をするだけです-ここでは違いはありません。モノリシックシステムで実行できることは何でも、サービスアーキテクチャで実行できます（たとえば、一括作成するユーザーの配列を渡した場合、または単一のものを作成します。サービスでもまったく同じことができます）。
MVCはすでに分離されたサービスの概念に基づいており、MVCフレームワークのみがそれらを単一のプロジェクトにバンドルします。それはあなたのフレームワークがあなたに与えているバンドルされたヘルパー以外のものを失うという意味ではありません。別のフレームワークを使用すると、別のヘルパーを使用する必要があります。または、この場合、独自にローリング（またはライブラリを使用して直接追加）します。
デバッグも簡単です。APIを分離して徹底的にテストできるので、デバッグする必要はありません（エンドツーエンドでデバッグでき、Visual Studioは複数のプロセスに同時に接続できます）。
セキュリティを実装する余分な作業のようなものは良いことです。現在、すべてのコードをWebサイトにバンドルしている場合、ハッカーがそのコードにアクセスすると、DBも含めてすべてにアクセスできます。 APIに分割した場合、ハッカーはAPIレイヤーもハッキングしない限り、コードでほとんど何もできません-これは非常に困難です（どのようにして攻撃者がすべてのWebサイトのユーザーまたはCCの詳細の膨大なリストを取得するのか疑問に思ったことはありませんか？彼らはOSやWebサーバーをハッキングしましたが、DBに直接接続して "select * from users" 簡単に）。
このように書かれた多くのWebサイト（およびクライアント/サーバーアプリケーション）を見てきました。私が金融サービス業界で働いていたとき、セキュリティリスクが高すぎるため、また開発の多くが安定した（つまり、レガシー）バックエンドデータ処理に対するかなりのGUIであるため、ウェブサイトをオールインワンで作成する人はいませんでした。システム。サービススタイルアーキテクチャを使用すると、DPシステムをWebサイトとして簡単に公開できます。
2番目の編集：主題に関するいくつかのリンク（OPの場合）：
Webサーバーのコンテキストでこれらについて話す場合、他の層を呼び出すのはクライアントであり、レンダリングのためにブラウザーに送信されるUIビューを構築するので、Webサーバーはプレゼンテーションレイヤーと見なされます。これは大きなテーマであり、アプリケーションを設計する方法はたくさんあります。データ中心またはドメイン中心です（通常、ドメイン中心は「より純粋」であると考えていますが、 [〜＃〜] ymmv [〜＃〜] ）、しかしそれはすべて、クライアントとDBの間にロジック層を固定することに帰着します。中間、API、層がモデルと同等であると考えると、MVCに少し似ています。モデルだけがDBの単純なラッパーではなく、よりリッチで、はるかに多くのことができます（たとえば、2つのデータソースからのデータの集約、ポスト） -APIに適合するようにデータを処理する、データをキャッシュするなど）：
現在、マイクロサービスが大流行していることは知っていますが、必ずしも価値があるとは限りません。はい、疎結合コードが目標です。しかし、それは、より苦痛な開発サイクルを犠牲にしてはなりません。
良い中間点は、ソリューションに個別のデータプロジェクトを作成することです。データプロジェクトは.NETクラスライブラリです。 ASP.NET MVCプロジェクトがデータライブラリへの参照を追加し、すべてのモデルがデータプロジェクトからプルされます。その後、デスクトップまたはモバイルアプリを作成するときに、同じコードを参照できます。したがって、公式のAPIではない可能性がありますが、1つのAPIとして機能します。 APIとしてアクセスできるようにする場合は、データプロジェクトのラッパーとして機能する単純なWebプロジェクトを作成できます。
Microsoftはこの概念を推進してきました。この概念は ポータブルクラスライブラリ と呼ばれています。
すべきではない。同じバックエンドにアクセスする代替のフロントエンド（モバイルアプリやデスクトップアプリ、または個別のウェブアプリケーションなど）を作成する計画がすぐにない場合は、ウェブサービスレイヤーを導入しないでください。 [〜＃〜] yagni [〜＃〜]。
疎結合は常に（高い凝集力と共に）望ましいですが、これは設計原則であり、異なるサーバー上のオブジェクトを物理的に分離する必要があるという意味ではありません。また、サービスAPIの設計が不適切な場合、サーバーの境界を越えて密結合が発生する可能性があるため、APIを使用しても疎結合が保証されるわけではありません。
将来サービスAPIが必要になった場合は、その時点でいつでも導入できます。コードを適切に階層化している限り（データアクセスとビジネスロジックがUIロジックから明確に分離されている）、現在よりも後で導入することは難しくありません。また、実際の要件を満たすように設計すると、結果の設計がはるかに良くなります。
注WebサービスAPIを作成する必要があるかどうかが問題だと思います。質問はAPIについてだけですが、APIはライブラリのインターフェースを意味することもあり、当然、当然ながらすべてのレイヤーにAPIがあります。つまり、ビジネスロジックとデータアクセスレイヤーは、デザインレベルでUIロジックから明確に分離する必要がありますが、Webサービスレイヤーが不要な場合は導入しないでください。
私の会社では、このように構築されたアプリケーションを1つ持っています。最初は、別の開発者が作成していたフロントエンド用のAPIを備えたバックエンドを構築するように依頼されました。他の開発者がそのフロントエンドを開発できなかったとき、私たちはフロントエンドの構築も依頼されました。このアプローチには間違いなくメリットがありますが、コストという大きなデメリットがあります。維持するコードが多くなり、2つの別々のシステムも展開するため、最初のビルドは大幅に高価になり、継続的なメンテナンスはより高価になります。追加のコストのため、これは常にビジネス上の決定であり、開発者が気まぐれで行う必要はありません。
それに数字を当てはめると、このアプローチのおかげで、前述のプロジェクトのコストは20％高くなると思います。あなたはどのような種類の会社でどのようなプロジェクトに取り組んでいるのかを説明していませんが、製品の構築を始めたばかりの場合、追加のコストが、製品を作るためのいくつかの追加機能の出荷の違いになる可能性があります成功。
少なくとも普遍的ではないもう1つの理由は、その2番目のインターフェースを作成する場合、または機能の1対1のマッピングがまれにしか存在しないことです。たとえば、モバイルアプリを作成すると、機能が少なくなる傾向があります。これは、一部のAPIメソッドが再利用されないことを意味します。したがって、同僚との妥協案として、最も重要で重要な呼び出しを決定してAPIに追加し、それ以外のものについては従来の方法を使用することが考えられます。
考慮すべきもう1つの点は、既存のコードを再利用することはできないと同僚が言っていることです。これは、ビジネスロジックがある程度分離されている場合は当てはまりません。内部APIの周りに薄いWebサービスラッパーを作成するだけでよく、これは特に大きなタスクではありません。とにかく、まったく変更を加えずに、別のフロントエンドでWebサービスレイヤーを再利用できると考えるのは簡単です。
それは、アプリケーションのタイプと、あなたがいる市場のタイプによって異なります。
この方法には、トレードオフと利点があります。ある方法が他の方法よりもbetterであるという明確な答えはありません。
個人的な経験からお話します。 2007年にこの方向に取り組むコードベースを採用することを決めたのは私でした。そのコードベースは、現在100万行程度のコードであり、その半分は大量のWebサービスの背後に隠されているサーバーコードです。 APIの残りの半分は、クライアント、デスクトップネイティブ、デスクトップWeb、モバイル、バックエンドの統合などの小集団です。この決定にはマイナス面もありましたが、20/20の判断で、もう一度やると思います。 。関連するいくつかのトレードオフを示します。
メリット
柔軟性。デスクトップエクスペリエンスを強化するためのモバイルアプリを構築するためのリクエストであっても、SAPのバックエンドと統合するためのリクエストであっても、呼び出すAPIがあれば、すべてが簡単になります。これらのリクエストを十分に受け取ると、APIに有機的に進化します。唯一の問題は、その前に標準のWebサービスがあるのか、それともWebサービスがカスタマイズされた内部APIなのかです。
（チームの）スケーラビリティ。私たちの場合、このAPIの上にすべての開発者グループが構築されています。さまざまなグループと話し合い、ニーズをまとめ、そこから多目的APIを構築する専任のAPIチームもいます。人々がAPIの上に何かを構築しているとさえ言われなくなって、それを行うすべての人が私たちの会社のために働くわけではありません。
セキュリティ。コードベースの安全でない部分と安全な部分を明確に区別することは、セキュリティを推論するのに役立ちます。 UIとバックエンドコードを混同すると、問題が混乱する傾向があります。
トレードオフ
柔軟性。 APIに何かを「適切に」組み込む作業を行う必要があります。特定の問題を解決するために、UIコード内からDBクエリをすばやく実行することはできません。また、実際に再利用可能なAPIでは、非常に多くのユースケースを考慮する必要があるため、通常、迅速な解決策は間違った解決策です。特に、すでにそこに非常に多くのクライアントコードがあるため、APIの柔軟性が低下します（そのため、バージョン管理されたAPIに移行しています）。
初期の開発速度。疑いの余地なくAPIを先に開発するのは時間がかかります。 APIの上に十分な数のクライアントが構築されている場合にのみ、それを取り戻します。しかし、APIが十分に汎用的になる前に、3つの異なるクライアント実装が必要であることがわかります。最初のAPI設計のほとんどが間違っていて、Webサービスの構築方法に関するガイドラインを大幅に改訂する必要があることがわかりました。
赤いニシン
あなたはこれらの束について言及しました。実際には重要ではありません。
抽象化。 APIは、製品が提供する必要のあるすべてのユースケースをカバーするのに十分なほど抽象化され、それ以上のものはありません。 Webサービスがなくても、これを行う内部APIがあるか、重複したコードがたくさんあります。複製よりも抽象化を好む。
サーバー側のMVCスタックを破棄します。最近では、ほとんどすべてのシステムでしばらくするとモバイルアプリが必要になります。その後、そのモバイルアプリに対応するWebサービスを構築するときは、いずれにしても、APIコンテキストで認証と承認を行う方法を理解する必要があります。 Webサービスでそれを行う方法が1つしかない場合、実際には作業量は少なくなります。
一括操作。通常、バックエンドジョブを起動し、ステータスクエリのジョブIDを返す一括APIを作成することで解決します。それほど大きな問題ではありません。
デバッグ。全体として、システムのトラブルシューティングが少し簡単になったことがわかりました。フロントエンドコードとバックエンドコードの両方にブレークポイントを設定することもできます。そのため、実際にはステップ実行するのはそれほど難しくなく、自動化されたAPIテストを構築し、運用システムを監視するためにAPIをインスツルメントすることができます。
多くの独立した操作。それは、物事をどのようにデザインするかという問題です。純粋なCRUD APIの使用を主張する場合、はい、この問題に苦しむことになります。ただし、CQRS APIを増強することは、通常は良い考えです。サービスがフロントエンドである内部APIがあることを確認したら、その内部APIを簡単に再利用して、特定のサービスを構築できます。シナリオの。
要約
十分に異なるコンテキストで使用されるシステムでは、APIはすべてのニーズに対応する最も簡単な方法であるため、自然に進化します。しかし、間違いなくYAGNIの事件が起こっている。トレードオフがあり、意味のあるものになるまで意味がありません。重要な点は、独断的ではなく、製品の進化するニーズを満たすために、アーキテクチャーのさまざまなアプローチに心を開くことです。
同僚が説明しているのは、サービス指向アーキテクチャです。これは、非常にスケーラブルで、テスト可能で、まともなコーディング方法ですが、実際には作成しているものに依存します。
SOAにはいくつかの重要な利点があります。これを列挙してみます。
スケーラビリティ
バックエンドは分離されているため、フロントエンドは単なるフラットファイルでさえ、単なる一連のテンプレートになります。フラットファイルは、CDNから提供するのに非常に迅速かつ安価です。それらを縮小して静的HTMLにプリコンパイルしてから、クライアント側のデータを取り込むことができます。
APIは一貫性を保つ必要がありますが、既存のテクノロジーを超えた場合、スタックを壊すことなく、より高速なテクノロジーに交換できます。たとえば、Goで再作成できます。これを少しずつ再構築して、サーバー間で負荷を分散できます。インターフェースが同じである限り、テクノロジーは抽象化されています。
テスト容易性
MVCは通常クリーンな状態から始まりますが、実際にはコントローラーが単一のリソースに集中することはほとんどありません。コントローラーメソッドが実行する処理が多いほど、テスト可能性は低くなります。
APIはこの問題を回避します。各API呼び出しはリソースをプルして提供します。クリーンでテスト可能。
懸念の分離を保証
あなたのフロントエンドとバックエンドは完全に離婚しています。フロントエンドを別の開発者またはデザイナーに与えることができます。これは、別のレベルに移行したMVCです。 MVCをあきらめたくないと思います。 SOAはMVCですが、まあまあです。
欠点
もちろん、いくつかの欠点があります。多くの場合、モノリスの方が処理速度は速くなります。慣れているかもしれません。スタックにうまく収まる場合があります。ツールはモノリス作成用に最適化されている場合があります。
これらはどれも、私の意見では特に良い理由ではありません。それらが当てはまる場合は、ツールの変更を検討することをお勧めします。
ここには良い答えがたくさんあるので、実装経験を追加します。
これは私が物事を行う方法です：
- すべて/唯一のDB対話を処理するデータベースアクセスレイヤーを作成します（通常、速度と制御のために手動のSQLが使用され、ORMは使用されません）。挿入、更新、削除、選択...
interface（virtual class）必要なAPI関数を公開/適用します。それらは、実装されると、高度に専門化されたDBAL関数を使用して結果を達成します。また、APIをコンパイラー・レベルで実施するのにも役立ちます。サーバー+ API実装にすべての関数が組み込まれていることを確認します。- インターフェイス（これは実際のAPIです）を実装し、セキュリティ制限を実施する2番目のレイヤーを作成します。ここでは、外部APIとも対話します。
- Webサイトは、リモートアクセス可能なAPI（SOAP、JSONなど）を経由せずに、2番目のレイヤーを直接使用します（パフォーマンスのため） 。
- スタンドアロンサーバーは、インターフェイスを実装し、第2層を実際のリモートアクセス可能なAPIとして外部のデスクトップ/モバイルクライアントに公開するビルドです（非Webサイトアクセス）。要求をデコードし、応答をエンコードし、クライアントを管理/切断するだけです。また、他の接続されたピアによって生成されたイベントをクライアントに一括通知するプッシュバック機能もサポートしています（Webサイトには通常必要ない機能）。
つまり、技術的には、APIは第2層です。 Webサイトで直接使用し、サーバーを介してリモートクライアントに公開します。 コードが再利用され、コードの再利用可能なチャンクがインライン化されることはありません。（このルールによって生きて死ぬ）保守性、テストに役立ちます。 ..すべて。
Webサイトをデスクトップ/モバイルAPIサーバーに接続することは決してありません（サイトがAJAXであり、JSONで実行されている場合を除く）。ただし、サイトがレンダリングされる場合マークアップ内の動的コンテンツ、中間APIを通過することでパフォーマンスが向上します。Webサイトは高速である必要があります！リモートクライアントアクセスは少し遅くなる可能性があります。
[〜＃〜] ps [〜＃〜]：はい、より多くのホイールが連動するため、メンテナンスは少し複雑になりますが、長期的には簡単です。したがって、プロジェクトがしばらく存続することが意図されていて、少し複雑な場合は、常にAPIを用意してください。また、各レイヤーを単独でテストする方がはるかに簡単です。
論点は、APIを使用する必要があるかどうかではなく、実際に「API」が何であるかです。設計されたAPIを使用する唯一の方法は、ランダムなコードの乱雑なAPIを使用することです。あなたは、APIが物事を「柔軟すぎる」ものにし、それが物事を管理不能にすることを書いています。これは、APIが何であるかを完全かつ完全に誤解していることを示しています。その誤解があなたとあなたの同僚の間で共有されないならば、あなたは完全に異なることについて議論することによって多くの時間を浪費します。
明確に定義されたAPIを使用しないことで、好きなことができます。定義上、これは最も柔軟なオプションです。また、定義上、「やりたいことは何でも」は依然としてAPIです。 APIのonlyジョブは、柔軟性を取り除くことです。柔軟性を排除することで、優れたAPIは、ユーザーが同様のことを同様の方法で行うように促します。
もちろん、悪いAPIは柔軟性が多すぎたり少なすぎたり、あるいはその両方を同時にもたらす可能性があります。本当に不十分に設計されたAPIは、「すべてがうまくいく」アプローチよりも速くプロジェクトを終了させる可能性があります。ただし、ベストプラクティスは、アプリケーションと並行してAPIを開発および進化させる有能なプログラマーを配置することです。
例
•多くの前後を必要とする多くの独立した操作。たとえば、一部のコードは現在のユーザーを取得し、ユーザーが管理者ロールにあることを確認し、ユーザーが所属する会社を取得し、他のメンバーのリストを取得し、それらを送信します。すべてのメール。それには多くのAPI呼び出し、または必要な特定のタスクをカスタマイズしたメソッドを記述する必要がありますが、そのビスポークメソッドの唯一の利点は速度ですが、欠点は柔軟性に欠けることです。
まともなAPIでこれが必要とするAPI呼び出しの数は、おそらく1です。はい、柔軟性がありませんが、なぜそれを柔軟にしたいですか
Short Version：コントローラーは事実上APIです。 ASP.NETはそれを覆い隠しているかもしれませんが
長いバージョン：
ビールに関する情報を提供し、オプションでビールを販売する基本的なMVC Webアプリについて考えてみましょう。ルートはどのように見えますか？
/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}
通常のWebアプリでは、次のような補助的なルートがいくつかあります。
/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete
Web APIでは、HTTPメソッドから推測されるため、これらは必要ありません。
上記の対称性を考えると、これはAPIとコントローラーが非常に接近しているために同じものになる可能性があるというかなり説得力のあるケースを作ると思います。
掘り下げた後、使用しているASP.NETのバージョンに応じて、これがmightの状態であると判断しました。古いMVC 5以前には、2つの実装を適切に統合するための規則とインターフェースがありません。古いバージョンでは、Webアプリはビューにデータを入力して返しますが、APIはHttpResponseを提供します。ただし、どちらの場合でも、意味的にまったく同じ応答が生成されます。
MVC 6を使用している場合は、両方を統合されたコントローラークラスで取得し、それが返すものを賢くすることができます。良いASPサンプルコードは見つかりませんでしたが、同じパターンのRailsコードが見つかりました。検討してください Diasporaプロジェクトからの「いいね」用のこのコントローラー 。各コントローラーメソッドには、「リソースの多い規則」で定義されたルートがあります here APIのLCRUDに相当する量。
ただし、実装を読むと、それぞれがHTML、モバイルHTML、またはJSONに応答する可能性があります。これは、ビューを見つけるための規則と組み合わせて、WebアプリとWeb APIを完全に統合します。また、すべてのメソッドが実際に各応答を提供するわけではないことにも注意してください（UIではAPIが必要としないメソッドが必要になる場合があり、その逆も同様です）。
Railsはしばらくの間対称性を受け入れており、それを非常に明確にしているのに対し、ASP.NETはこれをすべて遅くまで考え出したため、これはインピーダンスの不一致です。
推測：
使用しているASPバージョンによって異なりますが、同僚は正しいと間違っています。古いMVCバージョンでは、APIとアプリの違いにより、おそらく「ベストプラクティス」になりました。 ASP.NETのモデルでは、コードを適切に再利用できなかったため、APIを事前に構築しました。
新しいバージョンでは、統一されたコントローラーの基本クラスでコードを再利用することが容易になったため、統一されたコードを使用する方が理にかなっています。
ただし、どちらの場合でも、コントローラーは事実上APIです。
彼は、私たちのコードがあまりにも強固に結合されていると言いました。たとえば、デスクトップアプリケーションも必要な場合、既存のコードを使用できません。
さて、あなたは？そうでない場合、それはかなり無関係なステートメントです。
2015年にnewアプリケーションを作成する場合、サーバーで生成されたHTMLページではなく、APIを含むユーザーインターフェイスを真剣に検討してください。明確なコストがありますが、明確な利点もあります。
しかし、あなたが既存サイトを持っていて、いくつかの異なるインターフェースを（私が知る限り）持つ具体的な計画がない場合、彼のコメントは単に無関係です。
2006年にキャリアを始めたとき、このタイプのアーキテクチャは.NETの世界で大流行しました。私は2000年代半ばに構想された3つの個別のプロジェクトに取り組み、ビジネスロジックレイヤーとWebフロントエンドの間にWebサービスを配置しました。もちろん、最近のWebサービスはSOAP=ですが、それでも同じアーキテクチャです。フロントエンドまたはバックエンドのいずれかを切り替えて、デスクトッププログラムを開発することもできるというメリットが想定されていました。最終的にYAGNIは真実であることが判明しました。これが発生することは一度もありませんでした。今回は、プロジェクトをこのように分割するコストしか確認できませんでした。プロジェクトの1つからWebサービスを取り込んでしまいました（段階的に削除するために半年かかりました）他のことをしている）そしてチーム全体は幸せでした。それ以来、私はそのアプローチを試したことはなく、特別な理由がない限りしません。このアーキテクチャを試す5年の経験から、私はそれを必要とせず、専門家もいないことがわかりました反対のことを言うと私は納得するだろうと思います。
さて、私はビジネスロジックとコントローラー/プレゼンターの間のレイヤーを開発するために一生懸命努力しています。たとえば、サービスレイヤーがあり、クエリを公開したり、すべてのサービスにインターフェイスを使用したり、IoCを使用してコントローラーに挿入したりしません。私のアーキテクチャでWebサービスが必要になった場合は、妥当なコストでそれを導入できます。この費用を前払いしたくないだけです。
また、マイクロサービスのアイデアはとても気に入っていますが、私の理解では、マイクロサービスは水平層ではなく垂直モジュールを意味します。たとえば、Facebookを構築している場合、チャット機能は独自のサーバーに個別にデプロイされる個別のサービスになります。これは、私が推奨するタイプの独立したサービスです。
サードパーティはそれを使用しますか？はい、あなたはすべきです。
それほど遠くない将来に再利用する予定ですか？はい、そうする必要があります。
あなたはサードパーティであり、文書化-または文書化可能-またはサードパーティによる使用可能化APIは、確実な再利用性とモジュール性を提供します。
あなたは急いでいますか？いいえ、あなたはそうすべきではありません。
その後のリファクタリングは、ほとんどの方法論と教師が予測して伝えるよりも簡単で高速です。まったく機能しないことよりも、機能しているものがある場合（内部設計が悪い場合でも、リファクタリングが可能であり、リファクタリングされる可能性があります）の方が重要です。 （ただし、incredible内部設計、wohoo）
フロントエンドは理由のためにその日の光を決して見ないかもしれませんか？はい、あなたはすべきです。
これはよく起こりました。この理由を追加しました。
そして、少なくとも、再利用や再配布などを行うためのコンポーネントが残っています。
ここに良い答えがあります。これを部分的な回答として投稿します。それはおそらくコメントとしてより良いでしょう。ただし、多数の投稿に同じコメントを付けるのはよくありません。
YAGNIがAPIを作成しない理由であると主張することはできません。
APIは自然で論理的なテストのエンドポイントです。したがって、0日目から、APIを使用するtwoアプリケーション、UIとテストスイートがあります。 1つは人間用、もう1つは機械用です。それらは必然的に異なります。フロントエンドの動作のテストは、バックエンドの動作のテストとはかなり異なるタスクです。したがって、テクニック、そしておそらくツールは、完全に異なります。 APIを使用すると、ジョブに最適なツールを使用できます。さらに、APIによる分離により、フロントエンドのテスターはバックエンドの機能をテストする必要がありません。
また、APIは、フロントエンドのコーダーをバックエンドのコーダーの懸念から保護し、逆も同様です。これらは当社では非常に異なるスキルです。 APIを使用すると、最強の場所に集中できます。