If you are unfamiliar with APIs, "What is an API" might be helpful pre-reading.
My recent open sourcing of api-sports, a ruby gem that simplifies usage of the API-SPORTS.io sports data API, clarified for me that the well documented and repetitive nature of API library creation makes it a perfect use case for AI automation.
My recent open sourcing of api-sports, a ruby gem that simplifies usage of the API-SPORTS.io sports data API, clarified for me that the well documented and repetitive nature of API library creation makes it a perfect use case for AI automation.
It can be helpful to think of APIs as the primitive building blocks behind almost every application we use. One of the most successful APIs comes from Stripe, it is used to power payments across the world:
Millions of companies of all sizes—from startups to Fortune 500s—use Stripe’s software and APIs to accept payments, send payouts, and manage their businesses online.
APIs allow systems to programmatically share data and/or perform operations. Foundational to APIs working is trust that if instructions are followed, and credentials provided, a system will respond as expected. Essentially two systems are entering into a contract, and just like legal contracts documentation is critical to API contracts. In fact a lot of Stripe's early success is attributed to how well documented their API was:
The Typical API Integration Process
Starting to use a third party API is typically broken into three steps:
- Identify the API. If you're looking to charge a credit card you're probably typing stripe.com directly into your browser, if you're looking for sports data like me you're probably doing some additional sleuthing.
- Read the documentation. Documentation is as critical to an API as the hardware servicing the requests. Documentation will clarify everything from how to authenticate, what operations are supported, to pricing.
- Integrate or write an API library. At this point a developer is ready to start using the API. Many APIs will offer pre-build libraries to simplify integration, while others will expect developers to write custom code to make their requests. API-Sports didn't offer a ruby library so I wrote the api-sports gem, leveraging prior art from Chris Oliver, GoRails, and tolbkni/vultr.rb (thank you all).
While API usage is not new to me, in a world of Generative AI headlines I became increasingly aware that I shouldn't be spending time writing a library to integrate an API. Once a single resource is added and tested, it becomes incredibly repetitive to add additional resources.
What The "Near" AI Future Holds
The documented and repetitive nature of API integration work lends itself well to AI. Once an API is conceived and its "contract" documented (e.g. via Swagger API docs) AI will become responsible for the generation and maintenance of integration libraries.
Stripe's documentation highlights libraries in 7 different programming languages. Each of these libraries (e.g. stripe-ruby, stripe-go) are almost identical in structure, with one to one mappings to the resources provided by the API (e.g. there'll be a customers file of some kind in each library that corresponds to the customer resource).
Given that the only real difference between these libraries in syntax it's easy to imagine an AI generating and maintaining API libraries in the near future.
Every programming language comes with a collection of rules that describe what kind of character strings may be considered valid programs in that language, these rules specify the language's syntax. –– Understanding Computation
Is a request in Ruby really that different to a request in Go?
# Ruby
Stripe::Customer.retrieve('cus_random_task')
# Go
c, _ := customer.Get("cus_random_task", nil)It'll be fun to see where we end up. I know for a fact that GitHub Copilot already helped me write better tests when creating the api-sports ruby library:
PS: Thanks again to Chris Oliver, GoRails, and tolbkni/vultr.rb for publishing great content and code that inspired how I structured the api-sports gem.