3

この質問は、しばらく前から私の頭の中にあります。

API (SOAP、REST など) を備えた PHP Web サイトがあり、この API は、ページ (ブログ投稿、コメント、統計など) で利用できるものとほぼ同じものを提供しているとします。

コードの冗長性/重複を避けるために、サイト自体でも API を使用することを考えています。なぜなら、ほとんどのコードの因数分解は MVC のモデルを使用して既に行われていますが、サイトが API を提供する必要がある場合、一部のロジックはまだ二重になっているためです。 .

訪問者が特定のブログの投稿を取得する場合の例:

クラシック GUI:

  1. HTTP リクエスト: ブラウザから送信
  2. PHP コントローラー: ユーザー入力の読み取り
  3. PHP モデル: データベースから投稿を取得する
  4. PHP コントローラー: ビューに入力する
  5. PHP ビュー: HTML のレンダリング
  6. HTTP 応答: ブラウザに送信

API を使用した GUI:

  1. HTTP リクエスト: ブラウザから送信
  2. PHP「投稿」コントローラー: ユーザー入力の読み取り
  3. HTTP API リクエスト: PHP コントローラーによってサイトの API URL に送信されます
  4. PHP "api" コントローラー: API 要求の読み取り
  5. PHP モデル: データベースから投稿を取得する
  6. PHP "api" コントローラー: "api" ビューに入力します。
  7. PHP "api" ビュー: レンダリング (XML、JSON など)
  8. HTTP API 応答: ポイント 2 の PHP コントローラーに送信されます。
  9. PHP コントローラー: ビューに入力する
  10. PHP ビュー: HTML のレンダリング
  11. HTTP 応答: ブラウザに送信

私の意見では、GUIは API を消費するレイヤー (新しいレイヤー) であるべきですが、PHP Web サイトでは、API 呼び出しが HTTP リクエストを介して時間がかかるため、パフォーマンスの問題が懸念されます。

4

1 に答える 1

1

Generally, you don't want to have the server make "inner" calls like that to itself. Instead, have the initial HTML include Javascript which drives the interaction:

  1. HTTP request for GUI: sent by browser

  2. HTTP response: static HTML (heavily cached)

  3. HTTP API request: sent via AJAX to site's API URL

  4. PHP "api" Controller: read API request
  5. PHP Model: fetch the post from database
  6. PHP "api" Controller: populate the "api" view as JSON

  7. HTTP API response: sent to browser of point 3.

  8. Javascript: alter the DOM

The "extra" call takes time but RESTful architectures strive to optimize user-perceived performance via caching (often resulting in no network activity at all) just as much as chunking. See a previous answer of mine for more analysis.

于 2012-07-07T00:10:54.283 に答える