网站使用自己的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)