6

完全なアーキテクチャのアイデアについて、さまざまな質問があります。私はほとんどすべての可能性に行き詰まっているので、素晴らしい経験を持つ誰かが私を助けてくれることを願っています。

コミュニティのウェブサイトを書き直す予定です。お客様は、将来的にネイティブモバイルアプリを利用したいと考えています。したがって、これを考慮に入れる必要があります。このため、PHPフレームワークKohanaに基づいて100％RESTAPIアーキテクチャを作成することにしました。Kohanaを選択したのは、これにより、余分な労力をかけずに内部APIを他のサーバーに簡単にスケーリングできるためです。（KohanaはHTTPとしてではなく内部URL要求を脅かしているため、最初はそれほどオーバーヘッドがなく、コードを少し変更するだけでHTTPに拡張できます）。

最初はAPIが非公開になりますが、後で、より多くのサービスが簡単に接続できるように公開する可能性があります。

基本的なREST構造は次のとおりです。

  1. / cats
  2. / cats / 1
  3. / cats / 1 / custom

たとえば、「カスタム」は「子」になります。

同じことが当てはまります：

  1. / ads
  2. /入札
  3. / users
  4. /バナー
  5. 等..

モバイルアプリは間違いなくこのすべての機能を使用するため、これらはAPIに最適なエンティティです。

したがって、WebサイトのコアはRESTであると結論付けることができます。ですから、基本的には、将来的にはネイティブアプリと同じようにウェブサイトをAPIのクライアントにしたいと思っています。このようにして、メンテナンスがはるかに簡単になります。

しかし、私が心配しているのは、これだけではありません（アップロードされたファイルの管理、請求、請求のための自動メール、広告のための自動メールなど）。ファイルをアップロードするには、WebサイトからAPIにアクセスする必要があります。これは一般的な方法ですか？これを行わないと、Webサイトはアップロードロジックを実行するため、サイトはクライアントではなくなり、アプリ自体もなくなります。したがって、モバイルアプリはアップロードすらできず、APIとWebサイトの両方がアップロードフォルダーを認識する必要があります（重複ロジック）。

次のモジュールを作成することを考えました。

  1. コミュニティAPI
  2. コミュニティ-ウェブサイト

その時はApiがコアのようです。しかし....cronjobsなどはどうですか？これは単なる「クライアント」であるため、実際にはWebサイトの一部であってはなりません。モデルまたはAPIと直接対話する必要があると思います。つまり、基本的にAPIはコアへのゲートウェイのようになり、これが必要だと考えました。

  1. コミュニティコア
    • モデル
    • cronジョブ
    • 自動メーリング（cronジョブの一部）
      • 請求書など
  2. コミュニティAPI
    • HTTPを介してコア内のモデルと対話する
  3. コミュニティ-ウェブサイト
    • Webサイト
    • 管理者

コアcronジョブは、REST構造の例外です。APIを経由せずにデータを変更できるのはこれらだけです。それらはコアに属し、APIはコアの上にあるので、少なくともそれは私の考えでした。

しかし、設計上、それはちょうど間違っているようです。操作はAPIのみを経由する必要があります！

別：

  1. コミュニティコア
    • モデル
  2. コミュニティAPI
    • HTTPを介してコア内のモデルと対話する
  3. コミュニティビジネス
    • cronジョブ
    • 自動メーリング（cronジョブの一部）
      • 請求書など
  4. コミュニティ-ウェブサイト
    • Webサイト
    • 管理者

これは私には設計上良く見えます。 （出典：mauserrifle.nl）マインドマップのイラスト

主な質問

1）

cronジョブはAPIまたはコアモデルを介して操作する必要がありますか？

2）

私の請求書のcronjobには、もちろんメインのWebサイトのスタイルとほぼ同じテンプレートが必要です。しかし、私のcronジョブがビジネスまたはコアの一部である場合、メインのWebサイトについての知識はありません。これを解決するのに何が理にかなっていますか？

3）

私のウェブサイトはテンプレートエンジンとして口ひげを使用します。（phpとjavascriptの両方がこれらのテンプレートを解析できます）。私はajax呼び出しにAPIを直接使用することを考えましたが、その後気づきました：

このサイトはAPIからデータを取得し、テンプレートのタイムスタンプを日付（Ymd）にフォーマットしてから、レンダリングします。javascriptにAPIを直接呼び出させる場合、javascriptにもロジック（フォーマット）が必要です。これは重複コードです！唯一の解決策は、ajax（apiとformatsを呼び出す）のWebサイトを呼び出し、フォーマットされたjsonを返すことのように感じます。私は正しいですか？

しかし....広告を削除するような単純な呼び出しは、APIを直接通過することができます（例：DELETE：/ ads / 1

さまざまな電話がかかってきます。

これに対するより良い解決策はありますか？

4）

全体：私のアーキテクチャは複雑すぎますか？私が考慮すべき代替案はありますか？

私はあなたのフィードバックを聞きたいです！

4

3 に答える 3

3

Webアプリケーションを開発する良い方法は、 API中心のWebアプリケーションを開発することだと聞いたことがあります。私にとって重要なのは、メインサービスをパブリックAPIに結合して、API中心のアプリケーションを構築すると、パブリックAPIを開発するという全体的なポイントがまったく失われるということです。

于 2012-02-27T12:51:26.383 に答える
2

これは私には論理的ではないようです。

はい、APIとWebサイト、そして次に来る可能性のあるものは別々のものであり、WebサイトはAPI自体のクライアントである必要がありますが、それは物事を大幅に簡素化するため、ドメインクラスを再利用して構築およびベース化する必要があると思いますあなたのウェブサイトの論理。このようにして、すべて同じコードベースを使用し、広告、請求書発行、そしてもちろんファイルのアップロードを含むすべての問題を簡単に処理できます。

パブリックAPIの場合、問題が発生してもメインサービスに影響を与えないように、可能であれば同じドメインクラスを異なる認証方法で再利用するために、別のボックスに配置する必要があります。

cronジョブは、API自体を介して呼び出しを実行するためにのみ使用する必要があり、それらの呼び出しはメインアプリ（APIを介したWebサイト）で行う必要があります。

ベースと同じコードを使用し、その周りにWebアプリをラップするなど、自分自身を繰り返さずにWebサイトを構築する場合、q＃2で問題が発生することはありません。

同じことが質問番号3にも当てはまります。WebサイトをAPIでラップすると、Webサイトは個別のエンティティでなくてもAPI自体を使用できます。

あなたのアーキテクチャは複雑に見えますが、これらのことをすれば、それは単純になります。;-)

幸運を！

于 2012-02-26T21:33:08.690 に答える
0

RESTは、リクエストを開始する1つの方法にすぎません。リクエストを処理するコアコードは、RESTインターフェース、またはHTTPと緊密に結合されるべきではありません。REST APIを、インクルードファイルなどへの単純なマッパーとして設計することをお勧めします。その後、cronはREST API全体をバイパスし、ファイルを直接含めることができます。リクエストインターフェイスを、実際の処理を行うコードから分離します。

于 2012-02-26T23:27:46.833 に答える