2016-07-19 15 views
0

我正在開發(第一次)開發由PHP RESTful API(可能使用peej/Tonic)驅動的PHP應用程序。來自直接訪問的應用程序可能會在頁面加載過程中進行20次不同的數據庫調用,我試圖調和20 API調用= 20x握手(可通過Guzzle持久連接進行改進)的事實,以及20x連接到數據庫。PHP中的RESTful API - 優化連續請求?

我相信通過更好的編程和規劃,我可以將我所需的API調用降至每頁4-5。在這一點上:

a)考慮到所有其他可用的優化,是否不值得考慮5x數據庫連接的延遲+每頁加載5x握手?

b)有沒有一種現有的方法可以減輕我迄今爲止找不到的方法?我相信它違反了RESTful編程的原則,但是如果我有一個API方法本身從其他API端點收集信息(例如GET GET WHERE x = y然後GET供應商的產品),那麼是否存在一個記錄內部API交互的方法(特別是在peej/Tonic或其他框架內)。

謝謝大家提前給你的智慧。

+0

您可以像Facebook一樣實現批量請求端點。 https://developers.facebook.com/docs/graph-api/making-multiple-requests,或允許包含像Fractal這樣的相關數據(http://fractal.thephpleague。com/transformers/- 請參閱「包含數據」) – ceejayoz

+0

如果後端DBMS支持它,請確保其查詢緩存已啓用。在我的堆棧中,Qcache命中返回速度比我可以添加的任何其他複雜組件都快,可以提高查詢響應時間。 – YvesLeBorg

回答

1

記住客戶應該是「使服務器的‘請求’」,這是必須履行「這一要求。」服務器可能會「執行20個不同的數據庫查詢」來準備其響應,而客戶端不需要知道也不關心。

客戶端的點的角度的,「我不在乎什麼你告訴我,不如何你做到了。」

如果希望直接發送查詢響應給客戶端,客戶端,以「做骯髒的工作」這些數據,那麼你仍然可以設計你的服務器的請求,這樣服務器做許多查詢,所有一次,併發送所有的結果集回來...在一個交換。

您的首要任務應該是有效減少發生的交換次數。返回數據量(合理範圍內)是次要的。

還要考慮到「當服務器這樣做時,工作自然會同步。」當客戶端發出多個異步請求時,這些請求是「異步」。考慮哪個策略對你來說更容易調試。

如果服務器被給出「請求執行」,它可以驗證請求(從而檢查客戶端錯誤)並執行任意數量的數據庫操作,可能在TRANSACTION中。這種服務器扮演着非常活躍的角色的策略通常比由服務器扮演被動角色的客戶端驅動的交互複雜得多。