通过API进行数据分配--单个开发者能做到吗？

这篇文章探讨了通过API进行数据分发，它的好处，以及一个人如何创建API来促进这种数据供应。

数据分布和你的数据可用性策略是任何数据部门的核心。一个组织的数据被集中起来并整齐地捕获，但用户却无法访问这些数据，这并没有帮助。有很多选择，根据你的组织，你可能需要一个组合的选项来满足所有用户的需求。

其中一些选项包括

• 策划的视图
• 按计划导出静态文件
• 前端数据访问
• 通过API访问

通过API向你的用户和你的组织中的其他团队提供数据正成为一个相当流行的选择，而且它有很多优点。

在这篇文章的上下文中，当我指的是REST API时，我们将提到一个API。REST API是一种使用HTTP请求与服务器交互的网络API。

这篇文章将探讨通过API分发数据，它的好处，以及一个人如何创建API来促进这种数据供应，并提供足够的文档。

API是一种有效的数据提供策略

我曾在许多使用传统数据提供机制的数据团队中工作过。

• 策划的视图

  • 虽然你可以给用户提供他们需要的东西，而且这些视图可以是高度定制的，但是你让用户直接访问你的数据集市。这似乎不是一个大问题，但安全和管理会成为一个令人头痛的问题。这是迄今为止最简单的选择，也是最不安全的，许多基础设施工程师会强烈反对。如果你不小心的话，也会有一些性能上的影响。

• 按计划导出静态文件

  • 在大多数组织中，你会看到一些东西，当文件被提取以适应目的时，有足够的机会出错。我个人遇到过一些最突出的问题，当文件由于网络问题、防火墙变化、驱动器可用性、空间限制或其他原因而没有被复制过来时。

• 前端数据访问

  • 虽然很好，但你往往需要特殊的工具，如MDS或替代工具或前端开发技能。

我相信还有很多其他的原因我可以补充到上面，但是API呢？它们对于数据供应来说是可行的吗？

• API按请求提供数据，意味着用户和团队可以在需要时访问数据。
• 你可以提供一个定制的端点，这意味着用户得到的数据正是他们所需要的。
• 如果你使用REST，数据通常是JSON格式，使数据的摄取和与现代系统的整合更容易。
• 它（可以说）更容易管理API的访问和安全，安全是根据你的规范，意味着你可以与你的组织要求一致。
• 容易分发文档 - 使用一些平台，你可以将API的文档与API一起托管，这是Linx的一个方便的功能。
• 可重用性 - API可以提供给需要数据的人，他们可以使用你预先创建的端点。
• 在调用API的时候，可以访问实时数据。这是我个人遇到的一个问题，客户想要访问实时的、时间点的数据，但数据是通过一个文件按计划提供的。你可以理解，当他们需要消费这些数据时，这些数据不会是 "实时 "的。

现在我们已经了解了为什么API可以帮助向你的用户和客户提供数据，让我们来考虑开发一个API的可行性。

API的挑战--开发

API的开发可能具有挑战性，这不是什么秘密，特别是如果它不是你的专长。为了成功地开发一个允许你的用户检索数据的API，你需要设计、开发和托管该API。

这些活动中的每一项都有一系列细微的步骤，需要使用一系列的技能和工具。

设计 - 为了设计API，你可以选择使用类似OpenAPI 3.0规范的东西。这个规范将允许你记录REST API的外观，定义其交互，并作为文档使用。像Postman或SwaggerUI这样的工具对这一步很有用。

开发- 现在你有了设计，是时候进行编码了。你将需要对你将使用的工具、技术和标准做出选择。这一步还将涉及不同技术和系统的整合。通常情况下，一个将被用来向用户提供数据的API将涉及到连接到你的数据库、数据湖或数据仓库。你还需要考虑到安全和认证问题。

托管 - 现在你有了可行的代码，你需要托管它。托管变得很棘手，因为有很多可用的选择。你是要在内部自行托管，还是要选择云计算解决方案？你将如何处理安全和监控？你的预算是多少？如果你在选择托管你的API的地方时考虑这些问题，将会有所帮助。

传统上，这些活动中的每一项都有各种工具。例如，设计OpenAPI规范可以用YAML或JSON完成。编码可以用python、javascript、C#或低代码工具来完成。托管可以在内部服务器上进行，也可以通过云计算解决方案进行。这些都是工具，如果你不熟悉它们，你将需要学习。那么，为什么许多组织有多个团队来照顾API开发生命周期的不同部分就很合理了。

但是如果我的数据部门很小，甚至只有我一个人呢？那么，API是不是我无法企及的呢？这就是低代码工具发挥作用的地方。

API开发在你手中

低代码工具提供了一个替代传统软件开发的方法。它们采用拖放式界面，允许开发人员在没有编码知识的情况下快速创建应用程序。

Linx就是这样一个选择。有了Linx，我可以在20分钟内设计、开发和部署一个处于可操作状态的API。

我曾在一些环境和组织中工作，Linx被用来向客户和其他团队提供数据。例如，假设你的数据团队专门从事数据管道，从各种遗留系统和来源集中组织数据。你正收到越来越多的请求，要求以更简单、更现代的方式直接访问数据，而不使用策划的视图。所以你选择了REST APIs。你要么需要提高你的团队的技能，使用编程语言和现有的框架来创建这些API，要么你可以通过选择一个低代码的替代方案，如Linx来节省时间。

通过选择Linx，我体验到了以下好处:

• 由于开发界面是拖放式的，你可以得到开发速度这一常见的低代码好处。
• 我不必担心托管和监控，因为这一切都由Linx处理。
• 随着速度的增加，你可以提供更多的API，并更有效地专注于支持。
• 文档被托管在Linx服务器上，这意味着团队不需要为API申请文档。它已经存在并被托管，供他们阅读。
• 通过本地托管的API，可以轻松地进行API调试，这样你就可以在部署之前看到你的API将做什么，输出是什么。
• 支持更容易，因为有更大块的开发块。任何人，包括业务分析员，都更容易理解一个应用程序的作用。这也有一个额外的好处，那就是让你的初级开发人员更快进入状态。
• 一键式部署

这可能听起来好得不像真的，但也要注意使用低代码解决方案的缺点:

• 你需要投入一些时间来学习这个工具。如果你必须学习一个新的框架，这将是一个净零。
• 大多数低代码工具都是有价格标签的。你不可避免地要为便利性、开发速度、以及更容易的部署和托管付费。
• 要注意工具所具有的局限性。就Linx而言，有许多集成，你可以创建几乎任何后端开发。如果你需要，你还可以创建自己的SQL脚本和C#函数。然而，Linx永远只能用于后端开发。

用API向你的客户和团队提供数据不一定是一个可以实现的梦想。我真诚地相信，这对每个人来说都是触手可及的，其结果是为每个人提供一个更好、更优化的解决方案。

在我看来，使用REST APIs为你的客户和团队提供数据是一个没有问题的选择。只要让人们即时访问数据，而不需要笨重的文件，就能让数据消费者更高兴。