REST APIをビジネスレイヤーとして使用できますか？

PHP Codeigniter MVCデザインパターンを使用しています

そして私はある種の特定のビジネスプロセスを備えたこのプロジェクトを持っていました

私のアプリケーションでは、2つの既存のREST APIを扱います。

1. グーグル
2. トレロ

ビジネスロジックレイヤー（BBL）として機能するREST APIを作成するというアイデアを思いつきました

次に、モデルに直接アクセスして、ビジネスルールを作成するために必要なデータをフェッチします。

RESTクライアントを使用してBLLと通信するコントローラー、

パフォーマンスの悪いアプローチですか？

データアクセスレイヤー（DAL）とビジネスロジックレイヤー（BLL）の2つのモデルのレイヤーを作成する方が良いですか？

私があなたのアプローチで目にする問題は、あなたがたった1つのコンシューマー、つまりコントローラーのためにREST APIを構築しているということです、そしてそれはやり過ぎです。あるレイヤーから別のレイヤーにデータを渡すためだけにレイヤーを追加するのではなく、意味がありません。追加の利益のために自分で作業を作成することになります。

APIを便利にする（迅速な）方法の1つは、コントローラー（つまり、アプリケーション）が必要とする唯一のエンドポイントである場合です。このことを考慮：

突然、REST APIには目的があり、それはさまざまなデータプロバイダーに統一されたインターフェイスを提供することです。アプリケーションは、GoogleやTrello API、または将来使用する可能性のあるその他のデータプロバイダーについて知る必要はありません。RESTAPIについて知る必要があるだけです。

この設計は、多少便利ではありますが、アプリケーションが唯一のコンシューマである場合は、やりすぎです。REST APIを構築する全体のポイントは、アプリケーションが共有できるように公開されているインターフェースを公開することです。ここで重要なのは公開です。RESTAPIは世界中で利用できるため、安全でなければなりません。APIの認証と承認は単純なタスクではありません。1つのアプリケーションだけがAPIを使用する場合、なぜすべての問題を解決するのでしょうか。もちろん、実験して学びたいのでなければ。その場合は、是非ともやってみてください。

いずれにしても、パフォーマンスは問題になりません。追加のレイヤーを追加するので、明らかにオーバーヘッドが発生しますが、そのオーバーヘッドが大きくなるかどうかは、実装に完全に依存します。REST APIが単一のエンドポイントである場合は、キャッシングが発生する1つの場所でもあることをお勧めします。サーバー側のキャッシュだけでなく、REST APIを使用すると、ブラウザーのキャッシュを悪用するのが少し簡単になります。これを正しく行うと、REST以外のアプローチと比較して、アプリケーションの全体的なパフォーマンスが向上する可能性があります。

tl; dr：実際に目的を持たないものを構築しないでください（学習している場合を除きます）。

あなたの図面に基づいて、Googleとの対話、結果の取得、アプリ用のフォーマット化を処理するコントローラーによって呼び出されるモデルが存在するように見え、それがコントローラーに送信されてすぐに使用できるようになります。つまり、Google固有の詳細はすべてそのモデルに含まれます。trelloも同じです。そうすれば、消費するAPIをさらに追加する必要がある場合、すべてを適切に分離しておくことができます。

これは小さな詳細ですが、アプリ全体の設計では覚えておいてください。APIサーバーからサーバーへの情報の送信/取得で発生する可能性のある遅延を考慮する必要があります。言い換えると、Trelloサーバーが遅いかダウンしている場合にアプリが完全にハングアップしないことを確認してください。

Apisはセキュリティに配慮する必要がありますが、必ずしも「公開」である必要はありません。多くのAPIは企業間で公開されているものはありません。

私はこの本のほとんどを読みました-その短い、まだ初期のリリース、そして十分な例はありません-しかし、それは非常に最新で、すべてのphpであり、著者はAPIについて積極的に作成し、教えています。 http://shop.oreilly.com/product/0636920028291.do

著者は彼女のブログにphp rest api関連の投稿があります。 http://www.lornajane.net/blog

そして、API投稿のコメントを必ず読んでください！真剣にそれはあなたに非常に貴重な視点を与えます。

あなたがグーグル「ハイパーメディア」とAPIを提案します。あなたはそれを使いたくないかもしれませんが、API作成のための他のいくつかのテクニックを示します。

私はプログラマーに参加したばかりです-できればこの質問に賛成票を投じます！ほとんどの企業は、APIを使用または公開するための完全に新しいアプリケーションを作成することはできません。そのため、APIを既存のMVCフレームワークに統合するためのベストプラクティスを考え出します。これは非常に重要です。