作者：Bill Doerrfeld
翻译：数字兄弟
API存在可访问性问题。低代码API方法能否使它们对公民开发人员更具包容性和可访问性？
如今，大多数软件都开放服务，通过提供API与第三方SaaS集成。SaaS在面对客户个性化需求时，将自己变成业务的封装，开放API，支持前端，让客户快速搭建业务。
传统IT模式
APCIoud云+端模式
举个例子来说，对于有图像识别需求的企业来说，如果企业自己开发太过复杂，但是通过专门做人脸识别的公司开放这部分能力就可以快速有效的解决这个问题，同样适用于有支付、存储、即时通讯等等能力需求的企业。
以后app那么多，越来越多的合作会在不同的app之间展开，可以把API连接为以前的友情连接，把服务快速的链接过去，提供给用户。不管你要找的是什么功能，都可能有相应的API。
这些专门的实用程序可以帮助软件团队避免为其核心能力之外的事情重新发明轮子。它们是标准化的，而且大多数服务都是按照REST或GraphQL指南编程的。通过HTTP提供集成服务有助于将业务逻辑与客户端接口分离。此外，现在已成为 Linux Foundation 一部分的 OpenAPISpecification 已经成为一种标准的描述格式，使API更加定义和可互操作。
但是，尽管取得了这些进展，集成过程中仍然存在摩擦，即使对经验丰富的开发人员来说也是如此。每个API都是唯一的。阅读文档以进行身份验证和发现方法、参数和可接受的字段需要花费时间。它需要在Postman中测试请求，破译错误消息，并在企业独特的环境中设置调用。最重要的是，停机时间和重大更改是对线下依赖性的合理担忧。
API需要付出努力和维护，仅仅集成第三方API并不能构建功能完整的应用程序。然而，企业逐渐发现创建新的数字化工作流程的责任越来越多的落在非技术人员的身上，低代码解决方案开始成为企业的目标和绝佳选择。
我们如何才能更好地将API与已经构建的软件应用程序连接起来，并让公民开发人员获得收益？
如果低代码平台降低了API集成的障碍，那么更多的问题解决者就可以将业务实用程序组合在一起，创建更高级的内部应用程序。让第三方API对公民开发人员更具包容性可以促进API经济的发展，并使创造性的解决方案在整个企业中蓬勃发展。
API集成中的障碍
有许多问题阻碍了非技术用户和新手程序员将API驱动的业务逻辑插入到他们的应用程序中:
入职时间:设置账户，获取身份验证，阅读文档和测试调用来熟悉所有的内容都需要时间。
数据类型: 在标头中传递的数据必须符合显式数据类型，否则请求可能会失败。
解析:响应常常过于冗长;开发人员必须解析JSON对象响应来检索他们需要的数据。
编程语言:每种语言处理网络通信的方式不同，这意味着请求在每种语言中看起来都不一样。
破坏性变更:第三方服务经常变更，因此如果不积极维护集成，可能会面临破坏性变更。
不同的格式:有各种API标准。REST、SOAP、GraphQL的设计都略有不同。另外，webhook、事件驱动和发布-订阅模式都有微妙的通信模型。
安全性和合法性:如果API没有得到适当的保护，黑客很容易窃取用户数据或造成中断。
对着我们对实际实现的逻辑了解的越深入，诸如“存入银行存款”这样的简单编程任务都将变得越来越复杂。
此外，只是实现了集成的工作，这并不意味着我们已经拥有了功能齐全、安全部署在云中并且具有普遍访问友好的UI，单个应用程序可能有多个集成，这意味着必须为您连接的每个外部服务重复集成过程。
API分类
对于非专业开发人员来说，克服这些挑战是一项艰巨的任务，他们可能不太习惯通过命令行使用业务应用程序。随着集成扩展到公共API之外，这个问题进一步复杂化。
在最近对DronaHQ联合创始人兼首席执行官Divyesh Kharade的采访中，他确定了三个主要的API类别：
现成的SaaS API:Microsoft Teams、Slack、Sendgrid、Twilio、谷歌Sheets等。这些是与第三方运营业务实用程序和应用程序的连接。
连接到数据库:许多公司需要与定制的内部数据库或遗留的内部MySQL数据库进行安全连接。
内部定制软件:它们是私有的或合作伙伴的API。它们可能是新的api优先的微服务，或者定制的遗留内部应用。这样的中间件可能会公开许多API。
如果一个低代码的应用程序想要成为一个整体的软件开发附加组件，它必须预见到所有潜在的环境,这包括各种场景的集成现实。
公民开发人员与“非技术人员”
那 么，究竟谁从更易于访问的集成中受益呢？
“公民开发人员”这个术语通常是指那些受过很少编程培训的非专业软件开发人员。当大多数人说到公民开发者时，他们指的是能够构建技术的只能人员，Kharade说道。
正如我前面所说的，在 开发人员人才减少 以及影响软件开发需求 的其他因素共同作用 下， 培养公民开发人员的文化 已成为当务之急。
但是，公民开发人员倾向于对低码领域的每个人而言都有些不同。Kharade似乎更喜欢“非技术”一词。非技术用户可能包括设计师，他们可能没有软件背景，但具有相关的UX / UI知识来组装工作流。“设计是任何应用程序的重要组成部分，” Kharade说。
屏蔽API的复杂性
如果低代码工具掩盖了复杂性，并使这些非工程师更容易访问API，那么它可以激发出许多创造性的解决方案。 在低代码环境下，创造力是无限的。
例如，如果一个内部应用程序需要聊天功能，Slack可以是一个很好的补充。Kharade指出，低代码层可以隐藏后端复杂性，让人感觉不像是后台的请求。
解决方案是双向的。利用低代码平台来管理数据和公开API可以增强可见性和可扩展性。Kharade描述了一个工业制造用例，在今年的疫情之前轮班工人在纸上手动输入机器操作数据，一旦强制封锁，该公司就开始将这个记录保存过程数字化。这对实时数据的访问，以及过滤和组织历史数据的能力，已经很有帮助了。Kharade说，六个月后，他们可能会考虑如何使用API访问这些数据。
基于触发器的解决方案是一个开始
当然，像IFTTT和Zapier这样的工具已经让外行人可以访问API很多年了。 这些平台在复杂集成的基础上使用友好的、基于UI的前端，允许用户设置基于触发器的自动化。
这些都是将服务-服务通信连接在一起的工具。然而，这些工作流与更大的应用程序开发有点距离。例如，一个招聘员工的应用程序可能需要将一个表单API的输入连接到一个谷歌表单字段。这可能需要自定义数据库、上传文档的方法以及将应用程序部署到云的能力。
因为低代码已经有了用于拖放的标准组件，所以添加一个通用的方法来插入第三方API集成就像是对这些平台的一种自然的功能增强。
使集成更容易实现
到目前为止，ProgrammableWeb记录了23,000个API。显然，许多创新的、可编程的SaaS产品已经成熟。有些是付费的，有些是开放的，所有的集成都略有不同。
Kharade说，非技术用户很难注册API并与之交互。弄清楚身份验证、OAuth、报头、有效负载和响应需要专业知识。Kharade说，虽然专业开发人员可能需要注册一次，但是一旦建立了第三方集成，它们就应该是拖放并点击即可使用。
解决集成问题只是低代码平台能够发光的众多领域之一。如果平台能够成功建立(并维护)连接性，消费者就可以更容易地访问他们正在搜索的核心逻辑。在2019冠状病毒病危机期间，为传统的非技术公司推广强有力的解决方案尤其重要。
需要明确的是，我不认为满足最终用户的需求是API提供商的工作。相反，他们应该专注于创造优秀的开发者体验。当然，你试图构建的业务应用程序的类型以及对软件工程人才的访问将在一定程度上决定项目的技术堆栈。
也就是说，市场上似乎有更多低代码层开放集成的空间。API以同样的方式避免了为专门的实用程序重新发明轮子，低代码层可以标准化集成本身的麻烦。
- End -