库和API之间是否仍然存在差异？

Question

每当我向人们询问API和库之间的区别时，我都会得到不同的意见。有些人给出this kind定义，说API是规范，库是实现......

有些人会告诉你this type的定义，API是一堆映射的函数，而Library只是编译形式的分发。

这一切让我想知道，在网络代码，框架和开源的世界中​​，是否真的存在实际差异？像jQuery或cURL这样的库可以交叉到API的定义吗？

此外，框架是否完全交叉到这个类别？是否Rails或Zend的一部分可能更像“API-like”或“libraryesque”？

真的很期待一些有启发性的想法：）

Answer 1

我的观点是，当我谈到API时，它只意味着暴露给程序员的部分。如果我谈到一个“图书馆”，那么我也意味着所有在“引擎盖下”工作的东西，不过虽然是图书馆的一部分。

Answer 2

库包含可重复使用的代码块（软件程序）。

这些可重复使用的库代码通过 API 链接到您的程序  （应用程序编程接口）。也就是说，API是库的接口，通过它可以将可重复使用的代码链接到应用程序 简单来说，可以说 API是两个软件程序之间的接口，便于它们之间的交互。

例如，在像C这样的过程语言中，库math.c包含数学函数的实现，例如sqrt，exp，log等。它包含所有这些功能的定义。

可以使用describes and prescribes the expected behavior。

的API math.h来引用这些功能

Answer 3

API是库的一部分，它定义了它如何与外部代码交互。每个库都有API，API是所有公共/导出内容的总和。现在API的含义被拓宽了。我们可能会将网站/服务与代码交互的方式称为API。您还可以告诉某些设备有API - 您可以调用的命令集。

有时这些术语可以混合在一起。例如，您有一些服务器应用程序（例如TFS）。它有API，这个API是作为库实现的。但是这个库只是你而不是执行你的电话的人之间的中间层。但是如果库本身包含所有操作代码，那么我们就不能说这个库是 API。

Answer 4

我认为Library是一组所有类和函数，可以从我们的代码中轻松地完成我们的任务。但是库可以包含一些私有函数用于它的使用，它不希望暴露。

API是向用户公开的库的一部分。因此，无论我们有关于库的文档，我们称之为API Documentation，因为它只包含我们可以访问的那些类和函数。

Answer 5

我们首先要定义一个接口......

界面：是2个“事物”相互交谈并交换信息的手段。 “事物”可以是（1）人或（2）任何类型的运行代码（例如库，桌面应用程序，操作系统，Web服务等）。

如果一个人想要与一个程序对话他需要图形用户接口（GUI）或命令行接口（CLI）。两者都是人类（但不是程序）想要使用的接口类型。

如果正在运行的代码（任何类型）想要与另一个运行代码（任何类型）进行通信，它不需要或不需要GUI或CLI，那么它需要一个应用程序编程接口（API）。

所以回答原始的海报问题：库是一种运行代码，API是运行代码与其他运行代码交互的方式。

Answer 6

用简洁明了的语言

Library：为可重用性而存储的所有类和方法的集合

API：用户可以在其代码中使用的库类和方法的一部分。

Answer 7

根据我的观点，无论调用者可以访问哪些函数，我们都可以在库文件中调用api，库文件中有一些私有的函数，我们无法访问它们。

Answer 8

在谈到或想到API时有两种情况

1. 使用库的计算机程序
2. 其他（更广泛的意思）

我认为，在第一种情况下，关于API的思考令人困惑。这是因为我们总是使用一个库。只有库。没有库的API是不存在的，尽管有这样一种想法。

C ++中的标准模板库（STL）怎么样？这是一个软件库。

您可以拥有具有相同API 的不同库，这意味着可用的类，对象，方法，函数，过程或某种编程语言中喜欢的任何术语的集合。但是可以说，我们对某些“标准”库的实现不同。

可能有一个类比：SQL是一个标准，但可以具有不同的实现。您使用的始终是一些实现SQL的SQL引擎。您可以仅遵循标准功能集，也可以使用特定于该实现的扩展功能。

除了库的不同实现方式在效率方面的差异外，库中的“幕后”不是您所关心的。

我当然知道，这种思维方式不是什么“通常具有约束力的标准”。已经创建了许多新术语，这些术语并不总是清晰，准确，直观，这带来了一些混乱。当Oracle谈论集合时。它不是库，不是API，而是“ Collections Framework”。