New service APIMATIC is calling on API providers to try its tool that can auto-generate SDKs from an API. ProgrammableWeb spoke with founders Syed Adeel Ali and Zeeshan Bhatti about why providers should use their service rather than build their own SDKs.
Above: APIMATIC screenshot taken from the company's website.
“APIMATIC is an automatic code generator for APIs, specifically because SDKs reduce the time for developers to get started with your API,” says Adeel Ali. “But writing all of those SDKs is just not possible for new API providers.”
How to Turn APIs Into SDKs Automatically
Adeel Ali explains that APIMATIC — currently in beta — provides four ways for API providers to create SDKs on the fly:
1. From API Search to SDK Generation
“The idea is that your API description is listed in an API directory. For example, there is the Google API directory with a meta API for all of Google’s APIs, and we have integrated with the Mashape API directory.
“We give you everything you need to get started out of the box. We perform the code generation and give you a Zip file with a readme file, a folder with models and controllers, and then all the code is generated. We take care of authentications as well.”
2. Import Your API and Generate Code
“You can import Swagger or WADL descriptions of your API to get started. We are description agnostic, so you upload your JSON file, APIMATIC parses it, and then gives you an API specification page that gives the user access to their description to make it more flexible, for example.
“Once you are satisfied the API looks good, you can then invoke a validation stage that makes sure that your API code is robust, then you will start seeing the buttons Windows, iOS, Android, Java to create the SDKs automatically.”
3. Start From Scratch
Adeel Ali also says that, similar to the import API entry point, you can jump straight to the API description form page and input API specifications “directly from the account home page menu.”
4. Specify Your Endpoints
Finally, Adeel Ali describes what APIMATIC calls "code-generation-as-a-service." “We have an advanced REST client that helps specify an API. You simply fill in four fields and give the description, and then we will create the code automatically from that.”
Adeel Ali promises that there are “no black boxes; all code generated is open source code, and there are no restrictions on using the code.”
Getting API Providers to Auto-Generate SDKs
APIMATIC is encouraging API providers to try the auto-generation service for free during the beta stage:
“Although APIMATIC is generally useful for all type of APIs, we believe that our early customers have the following traits in common,” say Adeel Ali:
- They are early adopters of technology.
- They are focused more on mobile clients (iOS, Android, WinPhone).
- They do not currently provide SDKs or have a limited/community driven SDK availability.
- If they do provide SDKs, they want to reduce SDK update and maintenance costs.
- They provide public access to their API with developer communities ranging in size from hundreds to thousands.
- They built their API on good RESTful design conventions and their API supports JSON.
Adeel Ali is hoping API providers will test out the service, regardless of how they currently manage their API strategy. “It does not matter if the API provider already uses an API management provider or not. However, having access to an existing Swagger/IO Docs file would significantly reduce the time to setup APIMATIC account.”
At present, as part of its beat release stage, APIMATIC is hoping that successful examples of API providers building SDKs using the service will be success stories they can share in the future, while helping early adopters to be able to use the auto-generated SDKs to engage more developers. The founders confirm that while the service is free, as it builds its business model, it expects to provide a freemium SaaS-type approach.
In-House SDKs vs. APIMATIC: The SeatGeek Example
At present, to help speed up demonstration of the benefits of the service to API providers, APIMATIC appears to have started working its way through the Mashape API directory and converting listed APIs into SDK examples.
That’s how SeatGeek appears to have been listed. SeatGeek is a ticket search site that aggregates availability of events tickets from multiple sources and can offer sales discounts and event recommendations. Having third-party developers using their SeatGeek API has been an essential strategy for SeatGeek’s growth and is why the startup has been involved in fostering an active API developer community, such as through last year’s On Deck Cup series of hackathon events.
SeatGeek launched an open source iOS SDK for its developers to enable pulling out event data for iOS apps. “As developer time and focus is shifting to mobile apps, an integrated SDK can boost performance in a mobile app,” says Will Flaherty, director of communications at SeatGeek.
“I spoke with our mobile team, and it seems like APIMATIC were building off what we have in our API. It’s not as up to date as our SDK is,” Flaherty said after the SeatGeek mobile team had quickly reviewed APIMATIC’s generated SDK versus the version the developer team had created in-house and released two weeks ago.
While Flaherty sees SeatGeek's SDK as more advanced than what APIMATIC is doing, he does see a role for APIMATIC in helping other API providers build developer communities by helping speed up the SDK creation process.
“It’s great. It’s another touch point for using our API. One thing that’s neat about it is that you can use it across different clients. For us, we have a data SDK only in iOS, but we will have an Android SDK available in a month or so,” Flaherty says.
Of course, an in-house SDK would be expected to be better than what APIMATIC can create, but for smaller API providers and newer startups, APIMATIC may be a viable alternative. After all, SeatGeek has been around for several years and is only just able to devote the resources to building and maintaining a mobile SDK program. APIMATIC may be able to provide, at least, a short-term solution for API providers who cannot resource an SDK strategy of their own.
“Truthfully, it’s another layer of packaging for the core data,” says Flaherty. “In general, APIMATIC is a good thing. It’s definitely an ambitious effort, and we applaud them for moving in that direction.”
When to Use SDKs?
SDKs are a contentious subject in the API landscape: Everyone agrees you should have them, but many believe you shouldn’t be using them. The thinking — best summarized by John Sheehan from Runscope and Holger Reinhardt from CA Layer 7 — goes along these lines:
- SDKs are essential to getting developers to quickly start using an API.
- API providers need to invest in providing SDKs for the most commonly used languages in their developer community.
- API developer-consumers can then use the SDK to quickly prototype a product/application and test out an API.
- But by the time API developer-consumers are ready to build-to-ship, they are better off swapping to use the API directly.
- ... Or face potential disruptions and headaches as multiple variations of APIs and SDKs get upgraded and integrations disconnect between versions.
- Oh, and also SDKs are much heavier to add to an application’s final build than writing code specifically for the API functions needed in the application/product (Reinhardt says it is like packing 20 kilos of onboard luggage when you just need your toothbrush).
Adeel Ali has his own perspective on the value of SDKs:
Some while ago we read about how SDKs work until they don’t.
One criticism is that SDKs are very bloated, but with APIMATIC, you can be very fine-tuned. For example, you could focus on just 10 endpoints rather than all 100.
Many of the criticisms of SDKs go away when you use code generation and custom code generation.
API developers — both providers and consumers — can sign up for a beta account and gain access to the library of SDKs already generated or start creating their own SDKs using the APIMATIC tools.