APIs have an accessibility problem. Could a low-code API approach make them more inclusive and accessible for citizen developers?<\/p>\n
Most software today integrates with third-party SaaS. TomTom for geolocation. Stripe for payment. Twilio for SMS. Kairos for facial recognition. AWS for NLP … the list goes on. Whatever function you\u2019re looking for, there\u2019s probably an API for that.<\/p>\n
These specialized utilities help software teams avoid reinventing the wheel for things outside of their core competency. They\u2019re standardized, too \u2014\u00a0most services are programmable following REST or GraphQL guidelines. Serving integrations over HTTP aids in decoupling the business logic from the client interface. Furthermore, OpenAPI Specification<\/a>, now part of the Linux Foundation<\/a>, has risen as a standard description format, making APIs more defined and interoperable.<\/p>\n However, for all this progress, there’s still friction in the integration process, even for seasoned developers. Each API is a bit unique. It takes time to read through the documentation to authenticate and discover methods, parameters and accepted fields. It requires effort to test requests within Postman, decipher error messages and set up calls within your unique environment. On top of all this, downtime and breaking changes are legitimate concerns for over-the-wire dependencies.<\/p>\n APIs require effort and maintenance, and just integrating third-party APIs alone won\u2019t build you a fully functional application. Yet, organizations find themselves scrambling to find and hire engineers<\/a>, and increasingly the onus is on non-tech folks<\/a> to create new digital workflows. Naturally, companies are currently searching for even more low-code solutions.<\/p>\n So, what\u2019s the glue holding together API products? How can we better connect APIs to the software applications we\u2019re already building and<\/strong><\/em> allow citizen developers to reap the benefits?<\/p>\n My theory: If low-code platforms decrease the API integration hurdle, more problem-solvers can stitch together business utilities to create more advanced internal applications. Making third-party APIs more inclusive for citizen developers could boost the API economy at large and enable creative solutions to flourish throughout enterprises.<\/p>\n Perhaps the best way to demonstrate the need for low-code is to scare you with some code. Let\u2019s say you want your application to initiate a direct deposit into a bank account.<\/p>\n You don\u2019t want to build a financial service from scratch, so you turn to Stripe API. You set up an account, grab a key, and dig in to the ‘Getting Started’ materials. You peruse their comprehensive documentation<\/a>, and find out how to create a payout.<\/p>\n The docs<\/a> demonstrate a sample HTTP curl request for creating a payout. Other parameters to pass include If there are no errors with the request, the response will be a payout object, formatted in structured JSON. It details the balance, data created, currency type and other fields. It looks something like this:<\/p>\n Now, you can parse the response into data your application can ingest. You can also send other requests to update, return and cancel this payout object.<\/p>\n For specialists familiar with HTTP calls and JSON, this is pretty straightforward. Stripe docs typically generate sample requests for many languages, like PHP, Ruby, Python and others to help within your own environment.<\/p>\n But what if your users are more comfortable with UIs? Integrations are pretty opaque to the non-technical. Even for seasoned developers, APIs can quickly become too dense, and not all have a great developer experience.<\/p>\n There are many issues preventing non-tech-savvy users and novice programmers from inserting API-driven business logic into their applications:<\/p>\n As you can see, a simple programming task like \u201cmake a bank deposit\u201d becomes extremely complex the more closely we look at the logistics of actual implementation.<\/p>\n Furthermore, just because you\u2019ve made an integration work, that doesn\u2019t mean you have a fully-functional application, securely deployed in the cloud, with a friendly UI\u00a0 that’s universally accessible. A single application may have numerous integrations, meaning the integration process must be duplicated for every external service you connect.<\/p>\n Overcoming these challenges is a lot to ask of non-professional developers, who may not be comfortable consuming business applications from the command line. This issue is further compounded as integration extends beyond public APIs, too.<\/p>\n In a recent interview with Divyesh Kharade, co-founder\/CEO at DronaHQ, he identified three main API categories:<\/p>\n If a low-code application wants to become a holistic software development add-on, it must anticipate all potential environments. This includes integration realities for various scenarios.<\/p>\n So who, exactly, benefits from more accessible integrations? The term citizen developer<\/strong><\/a> is often used to refer to any non-professional software developer with minimal programming training. \u201cWhen most people speak of citizen developers, they mean functional guys that can build tech,\u201d says Kharade.<\/p>\n As I\u2019ve said previously, fostering a culture of citizen developers<\/a> is becoming a bigger priority amid dwindling developer talent<\/a> and a combination of other forces<\/a> impacting software development requirements.<\/p>\n Yet, citizen developer tends to means something a bit different to everyone involved in the low-code space. Kharade seems to prefer the term \u201cnon-tech.\u201d Non-tech users may include designers who may not have a software background but the relevant UX\/UI knowledge to assemble workflows. \u201cDesign is a big part of any application,\u201d said Kharade.<\/p>\n If low-code tools mask complexity and make APIs more accessible for these non-engineers, it could inspire many creative solutions. With low-code, \u201ccreativity is limitless, and integrations really help with that,\u201d said Kharade. \u201cOnce they see that power, they aren\u2019t going back again.\u201d<\/p>\n For example, if an internal application requires chat functionality, Slack could be a great addition. Low-code layers could hide complexity in the backend, to the point that it \u201cdoesn\u2019t feel like a request in background,\u201d noted Kharade.<\/p>\n The solution works both ways. Utilizing low-code platforms to manage data and expose APIs<\/a> could enhance visibility and extensibility. Kharade described an industrial manufacturing use case, in which shift workers manually entered machine operations data on paper. That was before COVID; once lockdowns were mandated, the company started digitizing this record-keeping process.<\/p>\n Access to real-time data, and the ability to filter and organize historical data, is already beneficial.\u00a0 \u201cSix months down the line, they may consider how to make this data accessible using APIs,\u201d said Kharade. \u201cThe journey has just started \u2014 it will only get smarter and better.\u201d<\/p>\n Of course, tools like IFTTT and Zapier have already been making APIs accessible to laymen for years. These platforms use friendly, UI-based front ends over the foundation of complex integrations, allowing users to set up trigger-based automation. If this particular service does this<\/strong>, this other service should do that<\/strong>.<\/em><\/p>\n These are cool tools for stitching together service-service communications. However, these workflows are a bit isolated from the larger application development picture. For example, an application for hiring employees may require more than connecting a form API\u2019s input to a Google Sheets field. This could require a custom database, a way to upload documents and the ability to deploy an application to the cloud.<\/p>\n Since low-code already has standard components for drag-and-drop, adding a common method to insert third-party API integrations feels like a natural feature enhancement for these platforms.<\/p>\n ProgrammableWeb records 23,000 APIs<\/a> as of this moment. Clearly, many innovative, programmable SaaS offerings are ripe for the picking. Some paid, some open, all with slightly different integrations.<\/p>\n \u201cIt\u2019s difficult for a non-tech user to register and interact with an API,\u201d said Kharade. Figuring out authentication, OAuth, headers, payloads and responses requires expertise. Though a professional developer may be required to \u201cregister them once,\u201d says Kharade, once third party integrations are set up, they \u201cshould be drag-and-drop and click-to-use.\u201d<\/p>\n Solving integration problems is just one of the many arenas where low-code platforms could shine. If platforms can successfully establish (and maintain) connectivity, consumers could more easily access the core logic they are searching for. Democratizing robust solutions<\/a> for traditionally non-tech companies is especially important amid the COVID-19 crisis.<\/p>\nThe Need for Low-Code API Integration<\/h2>\n
destination<\/code>, method<\/code>or source_type<\/code>.<\/p>\ncurl https:\/\/api.stripe.com\/v1\/payouts \\\r\n -u sk_test_4eC39HqLyjWDarjtT1zdp7dc: \\\r\n -d amount=1100 \\\r\n -d currency=usd<\/code><\/pre>\n{\r\n \"id\": \"po_1HmNKQ2eZvKYlo2CuRNBRWUW\",\r\n \"object\": \"payout\",\r\n \"amount\": 1100,\r\n \"arrival_date\": 1605116514,\r\n \"automatic\": true,\r\n \"balance_transaction\": \"txn_1032HU2eZvKYlo2CEPtcnUvl\",\r\n \"created\": 1605116514,\r\n \"currency\": \"usd\",\r\n \"description\": \"STRIPE PAYOUT\",\r\n \"destination\": \"ba_1HmNKQ2eZvKYlo2CzlT6m5gk\",\r\n \"failure_balance_transaction\": null,\r\n \"failure_code\": null,\r\n \"failure_message\": null,\r\n \"livemode\": false,\r\n \"metadata\": {},\r\n \"method\": \"standard\",\r\n \"original_payout\": null,\r\n \"reversed_by\": null,\r\n \"source_type\": \"card\",\r\n \"statement_descriptor\": null,\r\n \"status\": \"in_transit\",\r\n \"type\": \"bank_account\"\r\n}<\/code><\/pre>\nHurdles In API Integration<\/h2>\n
\n
API Categories<\/h2>\n
\n
Citizen Developer vs. \u201cNon-Tech\u201d<\/h2>\n
Masking the Complexity of APIs<\/h2>\n
Trigger-Based Workarounds Were A Start<\/h2>\n
Making Integration More Accessible<\/h2>\n