“One, as a member of a small team, I was personally responsible for documenting our APIs,” he said. “When we had a partner paying for a special set of APIs, I’d have to make a special set of documents for that partner. That was really annoying at a company of five people at the time.

“Second, the people who would consume the APIs expected us to deliver an SDK. I had to deal with that, and thought we could come up with a better solution.”

Swagger became a solution to both of these problems by establishing a standard way that RESTful APIs should behave and how they should communicate with developers. “Really, Swagger is a metadata layer or a description of what an API can do and how you use it,” said Tam. “As long as that description is succulent and provides consistent information, you can generate documentation automatically. You can generate clients automatically. You can generate documentation tools and sandboxes. That’s what started it. In 2011, we open-sourced the technology and kept going on our merry way building software for understanding technology.”

It wasn’t until 2012 that people started to pick up on Swagger. Today, it is at version 2.0 and has a massive list of companies inside its working group. “Once it started picking up traction, we realized it was something bigger,” said Tam. “It grew exponentially since then. Since our release, we’ve revised the specification four times. For the last version of the specification, we put together a working group of 500 companies and individuals, from Microsoft to garage startups, to regular people that wanted to participate in the design of Swagger. We put together this large working group and released the most current version in August 2014.

“The idea is really around saying ‘Here’s a way to describe APIs, and it makes everyone’s lives easier when it’s done that way.’ ”

Lorinda Brandon, API evangelist at SmartBear, agreed that Swagger appears to be the current hot topic in API management. However, she said that there’s still a lot of room for innovation and competition in the spaces that Swagger has been growing.

”Swagger is a very interesting player in the whole service description space,” she said. “Swagger 2.0 has a lot of momentum. They have developed this working group, they’re building the next-generation service descriptors based on the input of a lot of players in the industry. They’ve enlisted the help of a lot of high-profile vendors. The result is that there are some interesting things you can do with Swagger you can’t do with the other service descriptions.

“You can see, as the market evolves, all these service description languages starting to blend together. How do you collaborate across functions when designing and developing and iterating on an API? They’re all trying to solve the API as a product problem. There’s a lot of room to grow in there. What we’re starting to see is that all these players came from a different perspective, but they’re all starting to merge a bit. People will start standardizing on one or the other and service descriptors, and a lot of the functionalities will start merging together.”

Tam said that the future of APIs requires tools like Swagger, particularly as the number of RESTful, publicly accessible APIs continues to grow.

“I believe we see now APIs are everywhere, and everything needs an API,” he said. “Your car is going to have an API. The biggest challenges for consumers of APIs, ultimately, is that it’s just hard to connect to all these different styles and structures of services. There has been no standard. The reason why is that standards in the past have tried to solve everyone’s problems. Customer are revenue driven. I think we’re going to see more people moving to description formats because it’s going to be impossible to keep up with writing documentation for their APIs.”