An API without any officially supported clients is like a car without a steering wheel. It may be a great car,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
but you can't take it anywhere.
Yeah, it's possible to make a steering wheel, but that can be a time consuming and risky prospect. Surely, the manufacturer knows how to integrate steering wheels better than you ... right?
I'm a little embarrassed to admit it, but I've been a part of organizations that simply didn't have the desire to build out official clients for our API projects. "We can't support everything," we'd say, "We already have a big enough backlog as it is without having to learn an entirely new language."
While that mindset isn't a bad one, it is a little misguided. I'm not a Java developer, for example, so it feels inappropriate for me to build and support a Java library for other real Java developers to use.
Who am I, really?
It's not about code
The thing is, APIs aren't just about code anymore; they're about community. Developers rally around the APIs they love because the companies that build them respect their value and collaborate with the community to make them better.
No, I'm not a Java developer, but if I made an honest attempt at a Java API client and open sourced it to allow far smarter people to improve it, then I'm not doing other Java developers a disservice. I'm giving them a place to start, and working with them for the betterment of the API as a whole.
APIs without officially supported clients are a drain on resources and ultimately reflect poorly on the API itself. By expecting your consumers to integrate with your API from scratch, you are communicating that your API (and by extension your API consumers) are not a priority for your organization. Official, open sourced API clients indicate a higher level of support for your API while also encouraging open collaboration and discussion between you and your consumers.
PHP, COBOL, Ruby or C#?
Unfortunately, we all know that simply "having" official API clients isn't that simple. There are lots of things to take into consideration and plan for, the most important of which is how many languages to support.
A firm answer depends on the API itself and the abilities of your organization, but the three most common languages to support are Ruby, PHP and Node.js (although Go, Python and Java are also incredibly popular).
You should also keep a finger on the pulse of your community because its members might create libraries in languages you don't yet have a client for. While third-party clients might not necessarily fall under the umbrella of "officially supported," they can definitely be labeled as "officially recommended" by your organization. This is a great way to engage with your community while not taking on too much.
Listen to this podcast to hear Joel Shore and Will Thiel of Pointillist talk about making decisions for API technology within workflow.
Open source your API clients
Because you'll be building multiple open source projects in several different languages, it is crucial to be cognizant of the development and deployment best practices of each language.
While you may be a master at building and maintaining PHP libraries, for example, you might need to brush up on services like RubyGems or the Node Package Manager. Open source API projects mean that following best practices isn't optional because you are opening yourself up to critique by the community at large. In many cases, this is a valuable thing, but if you just half-bake it for the sake of saying you have a Python library, then you won't fool anybody.
Open sourcing your API clients is an amazing thing to do, but you should always be sure to set some ground rules for your community to follow. GitHub has excellent support for enforcing contributor guidelines and an awesome built-in issue tracker, but you can't automate your way to success.
Your API projects should, at the very least, have a README file that outlines every piece of important information about it. Consider the following issues:
- How do you run unit tests?
- Are you using a continuous integration/continuous delivery tool, and if so, how can contributors take advantage of it?
- What is the project licensed under?
These are all important things that, if addressed, will lead to the success of an open source project. That achievement, in turn, will lead to the success of your official API client.
In the end, building and managing official clients for your API should be a fun, community-building experience. While such endeavors increase your team's commitment to your API (hint: you're supposed to be committed to it), that dedication is always apparent to your consumers and your contributors.
Access our essential guide to API management
Discover some alternatives to REST for accessing object storage
Learn how to ensure that your enterprise APIs are secure