Manage Learn to apply best practices and optimize your operations.

In API projects, official clients aren't optional anymore

In the midst of API projects, remember that officially supported clients are must-haves these days to send a positive message to the API community.

An API without any officially supported clients is like a car without a steering wheel. It may be a great car,...

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

APIs aren't just about code anymore; they're about community.

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:

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.

Next Steps

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

This was last published in October 2016

Dig Deeper on API management strategy

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Do you open source your API clients? Why or why not?
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close