PHP中的API的最佳實踐：函數或類？

在我的公司我們開發了一些應用程序。我們必須爲一個應用程序（比如應用程序A）創建一個API，以便其他人可以使用它（它的數據）。PHP中的API的最佳實踐：函數或類？

的問題是：我們已經developped PHP類應用程序A的模式，如果我們想創建一個API，我們應該：
- 重新使用這些類（太多functionnalities一個API，太重...）
- 創建一個具有一些基本功能的PHP類，它接受輸入並只返回原始值（如字符串，數組...不復雜的類）
- 創建另一組PHP類，更簡單，並且只能被外部應用程序使用（所以只能用於獲取數據）

通常，API是第二種解決方案（與PHP一起使用，而不是用於e的Web服務xample），但是我發現它太糟糕了，我們做了一個複雜而有用的類模型化，然後我們把它分開，只是爲了有函數，字符串和數組。第三個在我看來是妥協，但我的一個同事堅持認爲這不是一個API。太糟糕了......

你覺得呢？

來源

2010-02-18 Matthieu Napoli

從架構的角度來看，解決方案編號3可能是最好的。基本上你使用的是一個Facade Design Pattern來簡化你的API。由於我目前正在處理此問題：在Patterns Of Enterprise Application Architecture中，此方法被描述爲service layer，因爲您不想將任何用戶（意味着將處理您的API的任何用戶）暴露於比實際需要更復雜的情況，期望。

這包括使用最簡單的接口和傳輸對象（如果它們是有意義的原始值）。一旦通過遠程服務（如web服務）調用Facade，您最終將不得不中斷repsonses並請求原始值（數據容器）。

來源

2010-02-18 16:48:32 Daff

謝謝，並感謝所有其他人。我會看看這個Facade模式，這就是它。 – 2010-02-18 21:38:35

構建一組簡化公共API的Facade類。

來源

2010-02-18 16:29:41

你的意思是選項3？（我想確定要明白，英語不是我的母語） – 2010-02-18 16:33:26

創建一些簡單的API來實現原始類。不要在包裝中重新實現任何業務邏輯 - 如果有任何邏輯發生變化，會導致您陷入麻煩，因爲您肯定會失去跟蹤哪一塊被修改，哪些不是。保持外部輸入/輸出簡單，如果你需要比字符串更復雜的東西，可以使用結構化數據的XML或JSON，但要儘量避免太複雜 - 如果你有兩件事情要通過，兩個查詢參數可能比一個結構好得多有2個領域。

這就是'立面'模式。

來源

2010-02-18 18:15:12 StasM

我也想說看看門面模式。構建一組Facade類，只提供真正需要公開的功能。那些類肯定會使用你當前的核心類。

這也給你帶來的好處是，如果你改變核心類，API不一定被改變。

來源

2010-02-18 19:34:53 enricog

PHP中的API的最佳實踐：函數或類？

回答

相關問題