API Transit Basics: SDKs
API Transit Basics: SDKs
In this post, we discuss the impact that Software Development Kits are having on the world of APIs and their integration into applications.
Join the DZone community and get the full member experience.Join For Free
The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
Supporting SDKs in a variety of programming languages can be difficult for some API providers. Luckily there is tooling available that helps auto-generate SDKs from API definitions, helping make the SDK part of the conversation a little smoother. Of course, it depends on the scope and complexity of your APIs, but increasingly auto-generated SDKs and code as part of a CI/CD process is becoming the normal way of getting things done, whether you are just making them available to your API consumers, or you are actually doing the consuming yourself.
- Swagger Codegen - The leading open source effort for generating SDKs from OpenAPI.
- APIMATIC - The leading service for generating SDKs from OpenAPI, and including as part of existing CI/CD efforts.
- RESTUnited - The easiest way to generate SDKs (REST API libraries): PHP, Python, Ruby, ActionScript (Flash), C#, Android, Objective-C, Scala, Java
Depending on your versioning and build processes, SDK generation can be done alongside all the other stops along this lifecycle. When you iterate on an API, you simply auto-generate documentation, tests, SDKs, and other aspects of supporting your services. Not all providers I talk with are easily able to jump into the aspect of producing code, as their build processes aren’t as streamlined, and some of their APIs are too large to expect auto-generated code to perform as expected. However, it is something they are working towards, along with other microservices, and decoupling efforts going on across their teams.
Once you realize an API definition driven approach to delivering APIs, the line between deployment and SDKs blurs–it is all about generating code from your definitions. Sometimes the code is providing resources, and other times it is consuming them. It just comes down to whether you are deploying code on the server or client side. Another significant shift I’m seeing in the landscape with SDKs, are things moving beyond just programming languages, and providing platform specific libraries for managing SalesForce, AWS, Docker, and other common components of our operations–further evolving the notion of what an SDK is and does in 2018.
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.