网站应该使用自己的公共API吗?


31

我开始写一个Web服务,并且已经使用nodeJS和RESTfulish方法构建了。

根据我的收集:

  • 好处是您不必重复代码。
  • 缺点是您:
    • 将经常更新公共API,但应通过版本控制解决
    • 不能真正进行服务特定的缓存和优化

什么是最佳做法?Stack Exchange,Github,Twitter等网站是否为客户使用自己的API?

api 

12
吃自己的狗粮也将驱使您改善公共API
Ben Brocka'5

亚马逊就是这样做的。
奥利弗·S(OliverS)2012年

2
要进一步说明OlverS的观点,请参阅Google Platforms Rant
Brian

Answers:


37

您应该绝对使用自己的API。这个概念被广泛称为“ 狗食”(dogfood),它具有避免代码重复的许多好处。

  • 您的网站/产品与API使用者将编写的内容之间的行为一致(即,他们对API的期望)
  • 测试的另一种形式。
  • 您可以并且会在客户之前找到API中的错误,从而降低解决方案的成本。

尽管我反对您的观点之一:您应该经常更新API。花时间设计和验证可以保留一段时间的API。幸运的是,以这种方式进行狗食会加强这一点。在您以前破坏客户代码的地方,现在您将破坏自己的代码。在必须时,可以使用版本控制解决方案,但应避免使用。


0

由于某种原因,它不允许我以问题发布者的身份登录,但是是我。我不能接受您的回答,希望可以,这很有意义。

但是,您怎么不想更新您的API?如何添加新功能,删除不受欢迎的功能,重构等?


嘿。这应该是对他的回答的评论-但我认为您没有足够的代表来评论。无论如何,关键是您不应该经常更新API 。即使那样,添加新功能也没问题-它不会破坏现有代码。为什么要删除不受欢迎的?使它们过时,并在人们长时间对否决做出响应后将其删除。
最多

2
API 添加方法很好,而更改现有API则不好,因为它将破坏依赖于该API的所有代码。
布莱恩·奥克利

@ stanm87:Max和Bryan说得很好。您应该避免更改API的约定(即接口和预期的,正常的行为)。人们将依赖于他们是否会使用您的API,如果您对其进行更改,它将破坏他们的代码。
史蒂文·埃弗斯

非常感谢您的澄清。@Max我确实无法评论他的回答
stanm87
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.