網站使用自己的API是不是很好的做法？

Question

在開發網站的同時開發API是否是一種很好的做法，因此網站本身實際上使用API​​？或者如果選擇這樣做會有性能下降嗎？

例如，有沒有人知道成熟的網站（如Facebook或Digg）是否使用自己的API來進行CRUD（創建，讀取，更新，刪除）還是他們有自己的後端？謝謝

Answer 1

我懷疑Facebook等使用他們自己的API。有幾個理由不使用自己的API網站本身：

1. 可以使數據訪問更高性能的使用數據庫，而不是直接做額外的要求和（反）序列。
2. 可能更容易實現memcached高效緩存等
3. 重要的是，你不必在擴展你的網站時符合你的公共API（你不想經常改變你的公共API，那隻會惹惱大家）

Answer 2

如果你正在使用一些例如MVC框架作爲後端，那麼你已經有了一些這樣的CRUD API，或者你可以使用像ORB框架這樣的東西，它們被定向到某個領域，例如DB，並使用它們的API來控制你的應用程序，它也可能是任何東西。

但我不建議您使用原始SQL，特別是在開始時。所以，告訴我服務器端語言您的偏好和Web項目的目標，社區可能會爲您提供一些新的想法。

Answer 3

不，不要編寫自己的CRUD工具或ORMS。有足夠的開箱即用框架，那裏已經完成了構建API /框架/實用程序的所有艱難工作 - 您可以通過使用它們來獲得生產力回報。他們也會考慮性能問題。唯一的懲罰是每個人的一個小的學習曲線。這就是說，你仍然可以定義一個標準的方式/實踐來使用這些API來確保隨着你的應用程序變得越來越大，它們的一致性（和可維護性）。

如果你想進一步保護自己免受變化（或對衝你的賭注），你可以抽象的第三方組件和框架，通過使用接口和依賴倒置（例如DI或服務定位器模式）

Answer 4

我認爲如果沒有瀏覽器本身就可以使用應用程序的低級接口，並且該網站應該使用該接口來完成它的工作，這是一個好主意。

該接口不一定是API本身，它可能是一個層級低於API的層級，並且API和生產網站都使用該接口。

如果API只是複製網站，這通常是一個壞主意。

即，以下是壞

# hypothetical example of bad duplication 

def website_update_blog_post(request): 
    user = request.username() 
    ensure_logged_in(user) 
    post = Posts.objects.upsert(request.post_title, request.post_body) 
    trigger_notifications(post) 

..... 

def api_update_blog_post(user, password, title, body): 
    verify_login(user, password) 
    post = Posts.objects.upsert(title, body) 
    trigger_notifications(post)