Question

在开发网站时开发API是不错的做法，以便网站本身实际使用API？或者如果选择这样做会有性能影响吗？

例如，是否有人知道Facebook或Digg等成熟网站是否使用自己的API进行CRUD（创建，读取，更新，删除）或者他们是否拥有自己的后端？感谢

Answer 1

我怀疑Facebook等使用他们自己的API。有几个原因不使用您自己的API用于网站本身：

您可以直接使用数据库，而不是执行额外请求和（反）序列化，从而使数据访问更具性能。
使用memcached等实现高效缓存可能更容易
重要的是，在扩展您的网站时，您不必遵守公共API（您不希望经常更改公共API，这只会让所有人烦恼）

Answer 2

我认为最好有一个应用程序的低级接口，你可以在没有浏览器的情况下使用它，并且该站点应该使用该接口来完成它的工作。

该接口不一定是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)

Answer 3

如果您正在使用某些例如MVC框架作为后端，然后你已经有了一些这样的CRUD API，或者你可以使用像ORB框架这样的东西，它们被引导到某个领域，例如DB，并使用它们的API来控制你的应用程序，它也可以是任何东西。

但我并不建议您使用原始SQL，尤其是在开始时。所以，告诉我你喜欢的服务器端语言和web项目的目标，社区可能会给你一些新的想法。

Answer 4

不，不要编写自己的CRUD工具或ORMS。有足够的开箱即用框架可以为您完成构建API /框架/实用程序的所有艰苦工作 - 您可以通过使用它们来获得生产力回报。他们还将考虑性能影响。唯一的惩罚是每个人的学习曲线很小。

尽管如此，您仍然可以定义一种标准的方式/做法来使用这些API，以确保随着您的应用变得越来越大而保持一致性（和可维护性）。

如果您想进一步保护自己免受变更（或对冲您的赌注），您可以使用接口和依赖性倒置（例如DI或服务定位器模式）抽象第三方组件和框架

网站使用自己的API是一种好习惯吗？

4 个答案: