18

在开发网站时开发 API 是否是一种好习惯，以便网站本身实际使用 API？或者如果选择这样做会影响性能吗？

例如，有谁知道 Facebook 或 Digg 等成熟网站是否使用自己的 API 来进行 CRUD（创建、读取、更新、删除），还是有自己的后端？谢谢

4

4 回答 4

14

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

  1. 您可以通过直接使用数据库而不是执行额外的请求和（反）序列化来提高数据访问的性能。
  2. 使用 memcached 等可能更容易实现高效缓存
  3. 重要的是，您在扩展站点时不必遵守公共 API（您不想经常更改公共 API，那只会惹恼所有人）
于 2010-08-28T11:30:21.247 回答
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)
于 2010-08-28T11:49:58.680 回答
0

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

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

于 2010-08-28T11:29:34.493 回答
0

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

也就是说，随着应用程序变得越来越大，您仍然可以定义使用这些 API 的标准方式/实践来确保一致性（和可维护性）。

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

于 2010-08-28T11:39:50.043 回答