API作爲網站和移動應用程序的核心

Question

我對完整的架構想法有不同的疑問。我希望有經驗豐富的人能夠幫助我，因爲我幾乎陷入了所有的可能性。

我打算重寫一個社區網站。我們的客戶希望在未來使用原生移動應用程序。所以我需要考慮這一點。正因爲如此，我決定創建一個基於PHP框架Kohana的100％REST API體系結構。我選擇了Kohana，因爲這樣可以非常輕鬆地將內部API擴展到其他服務器，而無需額外的工作。 （Kohana威脅內部URL請求不是HTTP，因此開始時沒有太多開銷，並且可以通過一些小的代碼更改擴展到HTTP）。

起初，API將是私有的，但稍後我們可能會公開讓更多服務輕鬆連接到我們。

德基本REST結構如下：

1. /貓
2. /貓/ 1
3. /貓/ 1 /自定義

'自定義' 可以是 '孩子的'例如。

同樣適用於：

1. /廣告
2. /投標
3. /用戶
4. /橫幅
5. 等。

這些是API完美的實體因爲移動應用程序肯定會使用所有這些功能。

所以我們可以總結出網站的核心是REST。所以基本上我想將網站作爲API的客戶端，就像將來的本地應用程序一樣。這樣維護似乎更容易。

我擔心的是，除此之外還有很多事情（管理上傳的文件，發票，發票的自動郵件，廣告的自動郵件等等）。上傳文件需要通過網站到達API。這是常見的做法嗎？如果我不這樣做，該網站將做上傳邏輯，這使得該網站不再是客戶端和應用程序本身。因此，移動應用程序甚至無法上傳，API和網站都需要知道上傳文件夾（重複邏輯）。

我想創建以下模塊：

1. 社區API
2. 社區網站

阿比似乎是核心呢。但是...... cronjob等呢？其實他們不應該成爲網站的一部分，因爲這只是一個'客戶'。我覺得他們應該直接與模型或API交互。所以基本上API變得更像一個門戶的核心，我想我需要這樣的：

1. 社區爲核心
   • 模型
   • Cronjobs
   • 自動郵件（cronjobs的一部分）
     • 發票等
2. 社區API
   • 交互通過HTTP
3. 社區網站
   • 網站
   • 聯繫

核心的cronjob核心模型s是REST結構的一個例外。他們是唯一可以在不通過API的情況下更改數據的人。至少這是我的想法，因爲他們屬於核心，API是核心。

但通過設計，這似乎只是錯誤的。操作應該只通過API！

備選：

1. 社區爲核心
   • 模型
2. 社區API
   • 互動通過HTTP在覈機型
3. 社區商業
   • Cronjobs
   • 自動郵件（cronjobs的一部分）
     • 發票等
4. 社區網站
   • 網站
   • 聯繫

這看起來通過設計更好的給我。 Mindmap illustration http://mauserrifle.nl/mindmap.jpg

主要問題

1）

應該cronjobs通過API或Core模式操作？

2）

我的發票的cronjob需要一個模板幾乎當然主要網站的風格。但是如果我的cronjob是業務或核心的一部分，它不會知道我的主要網站。解決這個問題有意義嗎？

3）

我的網站將使用鬍子作爲模板引擎。 （php和javascript都可以解析這些模板）。我想直接使用API​​的Ajax調用，但後來意識到：

該網站從API獲取數據，格式化時間戳時間（Y-M-d）爲模板，然後渲染。如果我讓javascript直接調用api，javascript也必須有邏輯（格式化）。這是重複的代碼！感覺像唯一的解決方案是調用網站的Ajax（調用api和格式）並返回格式化的json。我對嗎？

但是....簡單的調用，如刪除一個廣告可以去直接通過API（例如，刪除：/廣告/ 1

我收到電話的混合....

任何更好的解決方案此

4）

總：是我的建築太複雜？我應該考慮任何替代方案？

我很想聽聽您的意見！

Answer 1

一旦我聽說要開發一個Web應用程序的好辦法是建立一個API-Centric Web Application。對我來說，如果你將主要服務與公共API結合起來，構建一個以API爲中心的應用程序，那麼你就完全喪失了開發公共API的全部意義。

Answer 2

這似乎並不符合邏輯的我。

是的，API和網站以及接下來可能會發生的事情都是單獨的事情，網站應該是API本身的客戶端，但由於它將簡化事務，所以我相信您應該重新使用域類構建並建立您的網站邏輯。通過這種方式，您可以使用所有相同的代碼庫，並輕鬆處理所有問題，包括廣告，發票和課程上傳。

對於公共API，它應該是在一個單獨的盒子如果可能的話再使用相同的域名類別，但不同的認證方法，因此，無論可能出現問題，也不會影響主業務。

你的cron的作業，才應使用防火通過API本身的調用，這些調用應在主應用程序（通過API網站）

如果你建立自己的網站進行不重複自己動手，如同使用與基礎相同的代碼並將web應用程序包裝在其中一樣，您將不會在q＃2中引發問題。

同樣適用於題號3.如果纏繞在API的網站，該網站可以使用API​​本身沒有被一個獨立的實體。

你的架構看似複雜，但如果你做這些事情，這將是簡單的。;-)

祝你好運！

Answer 3

REST只是一個發起請求的方式。處理請求的核心代碼不應該與REST接口或HTTP緊密耦合。我建議將REST API設計爲包含文件或類似的簡單映射器。你的cron可以繞過整個REST API，直接包含文件。將請求接口與實際處理的代碼分開。