API Definitions Are Slowly Becoming More Important Than Having SDKs
API Definitions Are Slowly Becoming More Important Than Having SDKs
With the advent of new tools, technologies, and best practices, exploring APIs has become a more all-encompassing part of the lifecycle.
Join the DZone community and get the full member experience.
Join For FreeSnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
As the debate over whether you need an SDK for your API or not has rumbled over the last couple of years, API specification formats like OpenAPI Spec, Postman, and API Blueprint have been gaining traction. As this has progressed, I've asked myself several times whether or not API providers even need SDKs anymore. Not just because of the complexities of developing and maintaining them, but because more developers are using web clients like Postman and DHC to evolve their integrations.
Apigee Explorer and Swagger UI documentation demonstrated that many developers needed to play with an API as they were learning about what resources were available and how to use them. I think the evolution of API clients like Postman, DHC, PAW, and others have shown that this phase of playing, exploration, and non-code integration can go well beyond just integration and should actually be neverending across stops along the API life cycle.
It is just anecdotal at the moment, but looking at the API providers who have embedded the Get Postman Button on their sites like Clearbit, Cronofy, Best Buy, and SparkPost, it seems to me that having your API definition available for your developers is growing more important than having SDKs. Developers are getting more traction by loading the Postman Collection, and other common specification format into their client, testing, and other tooling, than they are cracking open the language library of their choice.
This is something I'll further validate through my research. One critique I have on this is that I'm seeing the benefits of this approach focus around Postman, which I'm a big fan of, and a user, but represents just a handful of stops along the API life cycle (client, testing), and not the wider spectrum that OpenAPI Spec and API Blueprint would offer. I have yet to see any of these formats follow my advice like Postman did and get to work on an embeddable solution for OpenAPI Spec and API Blueprint — giving Postman a significant headstart.
API providers need to be openly sharing their API definitions, API service providers need to be allowing for the run in, and import using the common API specification formats, and developers need to be fluent in these formats and functionality, as they will play an important role in the evolution of the space — one that I think will be more significant than the role SDKs have played, after this plays out.
With SnapLogic’s integration platform you can save millions of dollars, increase integrator productivity by 5X, and reduce integration time to value by 90%. Sign up for our risk-free 30-day trial!
Like This Article? Read More From DZone
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}