Posted on 07-07-2014
I’ve expanded my monitoring on the world of APIs, from just API management, which I’ve been doing for four years, into tracking on APIs across multiple buckets I'm calling design, deployment, management, monetization, evangelism, discovery, integration, aggregation, reciprocity, and real-time. I am always working to understand who the key players are across the API space, but also make sure they are categorized into one, or many of these expanding buckets--helping me quantify things.
It is always very interesting to see how an API service provider fits into more than one of these buckets, as well as when new players emerge to cater to just one of these buckets, like Apiary did with API design. Playing on this theme, I was introduced to new a new API service provider, called APIMatic the other day, who on the surface seems to cater to API providers with the automatic generation of SDKs, but really is a cross-over into API design, discovery, and integration, bringing a new perspective to the table.
Generating SDKs Is The Carrot
As soon as you land on the APIMatic home page, they state very clearly what they do "Automatic SDK Generation for APIs”. You can search common APIs that are available in the APIMatic API marketplace, import your own API definition, or build one using their web-based user interface—which pretty squarely makes APIMatic for API consumers, providing clear API integration benefits, but via the generation of SDKs.
GUI Tool For API Design
The third option for generating an SDK from an API, is using the APIMatic web-based user interface, which allows you to build a definition of your API, using a web interface—no coding necessary. You can create a new definition, manage its settings, define endpoints, and the underlying data model. When ready, you can generate your SDK, which is rendered, I’m guessing using the default APIMatic format, and then also allows you to generate mock APIs, and sandbox environments--pretty squarely in the world of API design for me.
Provides API Discovery
Then the first option for generating an SDK is from a marketplace of existing APIs, allowing developers to generate SDKs for the most common APIs they depend on. From an API provider standpoint, this is a huge incentive for generating machine readable API definitions like Swagger, and register with marketplaces like APIMatic. I’d say APIMatic starts with a very Mashape style API marketplace for discovery, but then quickly focuses heavily on quality SDKS, and API integration as the end deliverable.
Supporting API Integration
Since APIMatic generates the code that sits between your app and the API resources it depends on, it has a unique lens for looking into how your applications are using APIs. This provides an alternative approach to the proxies and tooling I'm seeing emerge to monitor, track, test, and report on API integration. I’m not sure of the pros and cons to this type of API integration, but think APIMatic vision is worth taking a closer look at.
Mobile Focused Software Development Kits (SDK)
APIMatic focuses on delivering mobile SDKs, for iOS, Android, Windows, and Java platforms. When I talked to the founders, they said they would eventually provide more web focused SDKs, but mobile is obviously a major driver of API consumption, and was the low hanging fruit.
Centered Around Machine Readable API Definitions
Everything about APIMatic is centered around API definitions. When you select to import an API, you are given the option to import APIMatic, WADL, Swagger, IODocs, GoogleREST, and MashapeJSON. Each of the APIs available in marketplace have a machine readable definition, as well as the web-based form builder generating a machine readable API definition as well. These definitions are then used to generate SDKs, mock interfaces, and full circle back to listing you in the APIMatic marketplace for discovery—if you wish to make your API public.
Quality Software Development Kits (SDK)
Another aspect I find interesting about APIMatic, is that they focus on not just generating code stubs, they focus on high quality SDKs. Which in an era where you here a lot of rhetoric around SDKs being poorly written, out of date, hard to maintain, and unecessary--this gives APIMatic a potentially important differentiator if they do it right. APIMatic takes pride in their code being well written, looking nice, and following good conventions--something that could go a long ways in benefiting both API providers, and consumers.
Seeing new breeds of API service providers continue to emerge, with even new perspectives on how the API lifecycle operates, makes me happy, and with everything centered around machine readable, common API definitions, I'm even more pleased. This is in sync with what I’m seeing come out of the API design, deployment, management, and integration providers I've been tracking on—that API definitions are increasingly driving all stops along the API lifecycle subway.
I will play with APIMatic some more. To be honest, I was approaching this from an API providers perspective when I jumped on the Google Hangout with them, and was pleasantly surprised when I saw that they crossed over into API design, integration, discovery, as well as management. Now that I have a good idea of what they offer, I will revisit what the benefits to API providers could be. At the very least, it is another carrot for API providers to be sure and generate machine readable definitions for their APIs—without it your APIs won’t be found, or be able to be imported, and drive the next generation of API tooling like APIMatic.
APIMatic is looking to meet API providers, and get your API listed, so if you reach out, make sure and let them know I sent you. If you use this link, and sign up, you will automatically be let into the beta users group--APIMatic is currently “invite only”.
Oh, I also had a good conversation with them about the possibilities around integration of APIMatic with API Commons, and distributed API search engines like APIs.io, using APIs.json—so more to come. Much more!
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- My Discussion Today With 6 Hypermedia Leaders At API-Craft in Detroit
- Getting To Know Jørn Wildt For The API Craft 2014 Detroit Hypermedia Panel
- Hypermedia Feels Like We Are Still Learning To Communicate With APIs
- Getting To Know Markus Lanthaler For The API Craft 2014 Detroit Hypermedia Panel
- Getting To Know Kevin Swiber For The API Craft 2014 Detroit Hypermedia Panel
- Getting To Know Steve Klabnik For The API Craft 2014 Detroit Hypermedia Panel
- New Indix API KickStart Program Reduces Costs For Developers
- Getting To Know Mike Kelly For The API Craft 2014 Detroit Hypermedia Panel
- A Shared, Distributed Experience(Metrics) Layer For The API Driven Application Stack
- Showcasing Your API Integrations With Other Platforms
- Increasing The Focus On APIs In Higher Education Is Important
- Getting To Know Mike Amundsen For The API Craft 2014 Detroit Hypermedia Panel
- The New StrongLoop API Server Provides A Look At Future Of API Deployment
- Models For API Driven Startups Built Around Public Data
- Will You Add Me To API Evangelist And How To Spot The Cool Kids
- When I Remix APIs Using Swagger How Do I Deal With Authentication Across Multiple APIs
- It Takes A Team Of Evangelists To Raise An API
- Support For Only Two Creative Commons Licenses In The API Commons
- Machine Readable Terms of Service Didn't Read Applied To APIs Via APIs.json
- API Deployment For Non-Developers Using Zapier, Google Docs, and APISpark
- State of Hypermedia Today @ API Craft In Detroit
- Need A Formal API Standard For Your Government Agency? Fork 18F's, And Make It Your Own!
- CORS Makes Your API Portable And Remix-able
- Chief Data Officer Needs To Make The Department Of Commerce Developer Portal The Center Of API Economy
- An API Definition As The Truth In The API Contract