Leading industry research firm, Gartner Inc., recognized API-based commerce platforms as the next-gen category of commerce evolution. But not all APIs are

GraphQL is an open source technology created by Facebook that is getting a fair bit of attention of late. It is set to make a major impact on how APIs are designed. GraphQL is primarily about designing your APIs more effectively, and being more specific about access to your data sources.

So what about Facebook? It built GraphQL because it needed something powerful enough to describe Facebook’s API structure, but easy to learn by mobile developers. It is seeing billions of API calls a day now, so we know it scales. As Facebook points out, the shape of the query mirrors the shape of the response, which is cool.

In summary GraphQL maps pretty well to new API-driven models such as serverless. Michael Unger from Neo4j feels REST is worth retiring. That said, technologies don’t die overnight. REST is hardly going to disappear overnight. But for a class of problems for high scale sites it’s we’re going to see significant adoption of GraphQL. Google Trends shows growing interest in GraphQL and gRPC. GraphQL maps to external consumption of APIs, with gRPC for internal. They’re both clearly spiking in interest.

Swagger (okay, now the "Open API Initiative"... more on that later!) is a framework for describing your API using a common language that everyone can understand. Think of it as a blueprint for a house. You can use whatever building materials you like, but you can't step outside the parameters of the blueprint.

There are other available frameworks that have gained some popularity, such as RAML, APIBlueprint, and Summation. But Swagger provides more benefits than just helping create clear documentation.

• It's comprehensible for developers and non-developers. Product managers, partners, and even potential clients can have input into the design of your API, because they can see it clearly mapped out in this friendly UI.
• It's human readable and machine readable. This means that not only can this be shared with your team internally, but the same documentation can be used to automate API-dependent processes.
• It's easily adjustable. This makes it great for testing and debugging API problems.