Over a million developers have joined DZone.

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.

· Integration Zone

Build APIs from SQL and NoSQL or Salesforce data sources in seconds. Read the Creating REST APIs white paper, brought to you in partnership with CA Technologies.

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.

The Integration Zone is brought to you in partnership with CA Technologies.  Use CA Live API Creator to quickly create complete application backends, with secure APIs and robust application logic, in an easy to use interface.


Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}