Postman API LifeCycle Platform Makes It Easy for Developers to Integrate External APIs
API lifecycle tool provider Postman — with an estimated developer community of over 3.6 million users — has released version 5 of its flagship app, which makes big strides in supporting continuous integration practices now being used by an increasing number of development shops.
The Postman app now provides a development environment that can be used to consume APIs, in addition to aiding in the design, testing, and documentation of internally-generated APIs. The new version also comes a revamped business model to make Pro features accessible to more developers at the free tier.
Like RepreZen’s recent update to its API lifecycle tool, Postman is now more focused on ensuring developers can update and manage their APIs within an overall continuous integration/continuous delivery pipeline. Unlike previous releases, the Postman Pro API is now available to all users.
“The core components are pretty simple,” explained Abhinav Asthana, co-founder and CEO of Postman. “You get the Postman Pro API key, and then in Jenkins or TeamCity you add the key and you specify Newman as a build step. You then use Postman as normal to author your API tests. That’s synced up to our servers which is connected to our testing tool, Newman. It checks if the test passes or fails. If the test passes, then your CI/CD tool like Jenkins or TeamCity can automatically take it. It makes iteration super fast.”
API Consumption as a Lifecycle Stage
This year has seen a massive shift in the API landscape with a much greater focus on API consumption becoming a mainstream activity of startups and enterprises. This alters the whole concept of the API lifecycle from a starting place of designing internal APIs, then testing them, creating documentation, opening them to partners and then to third party providers to build on them as microservices.
Now, the API lifecycle is being extended to a starting place of consuming APIs. The “consumed APIs” are like additional microservices available to the business that must be managed alongside internal microservices and APIs.
One of Postman’s key approaches is to provide collections, where users can group APIs — internal or third party — that they are using together for the one process. This makes it easier to identify join issues such as differences in field name nomenclature, different ways of defining time or currency, or different security and rate limiting rules.
For startups, this is incredibly useful for the emerging “no stack startup”: businesses that daisy-chain APIs together to create a new service and provide that to customers. With the evolution in financial technologies currently occurring, this no stack startup is expected to grow significantly over the next few years.
For example, a startup could offer a personal financial management (PFM) tool that draws a customer’s bank accounts into one dashboard and then applies algorithms to forecast savings potential based on available financial products. A communications PaaS API could then be used to inform customers of better ways to manage their money. All of this could be done by consuming APIs in a workflow.
For enterprises, the proliferation of SaaS tools means there is more siloed data that needs to be connected together. In Mary Meeker’s annual internet trends presentation in May this year found that enterprises use on average 1,052 cloud-based apps, with financial services enterprises reporting around 1,170 in use. This ranges from marketing and HR to CRM, sales, and productivity tools as well as IT and cloud storage.
Enterprises need to link the data that is running through many of these apps and are turning to the APIs of the SaaS tools to make integrations possible. Again, that brings a service like Postman’s collections and ability to create custom documentation to explain to internal developers how to link those APIs being consumed internally and to share examples and test outcomes.
Asthana sees this as a key benefit of Postman. “Postman is very interactive, but you don’t have to worry about deleting the data. When you put data in front of more people, they realize its value a lot quicker. They start building use cases, and mini applications.” That’s why Asthana sees the API lifecycle transition has having extended to now start with consuming APIs to then building APIs.
Documentation, Mock Servers and Monitoring
Asthana says there are four key features that are now available with the new version release:
- Documentation support.
- Mock servers.
- Access to Postman API.
Documentation as a Key Part of Testing
Postman 5 begins to take on some documentation content management system (CMS) type capabilities, with two key approaches. Users can now include example requests as part of their documentation. Asthana says this is part of an industry-wide best practice move where API designers are using metadata to improve documentation.
Asthana says that now in documentation, you can better explain: “This is the request, this is the response, and then you can add examples. In any part of Postman, you have complete access to markdown, detailed parameter descriptions, API terms and conditions, you can define specific status codes, for example, if it is sending a 404 response you can decide what happens then, so Postman lets you completely document your API.”
Documentation can then be shared internally with developers or to external readers, using an editable CMS that allows for users to publish web pages as API documentation, with customized domain, logo, and colors. Under the free plan, users are limited to 1000 page views of their documentation per month.
Asthana says that one trend he is seeing is that more users are including tests as part of their documentation. “Publishers who write tests want the tests to be documented so that people get a sense of what are the rules that make the test succeed. We are seeing documentation, testing and monitoring being much more closer together than perceived externally. We are seeing that devs want more closer scrutiny across these stages of development,” said Asthana.
Mock Servers, Monitoring
As part of this uptick in API testing, Postman’s mock servers allow users to simulate their API. “You can now operate your backend and frontend independently of your production API,” said Asthana. In Postman, users can create a collection of APIs or API endpoints, document some examples of how calls will be made, parsed and forwarded into other APIs. Asthana says this lets developers test the full workflow chain and ensure there is a smooth process and data handoff. With mock servers allowing different testing environments, Asthana says it makes it easier for teams to “work on each of your API development silos completely independently”.
Postman also includes some monitoring services. Postman’s feature allows developers to set up external monitors for APIs, with 1,000 calls to the monitoring service being provided under the free plan.
With both no stack startups and enterprise SaaS users, a tool like Postman that helps developers consume APIs is essential to manage the consumption (and API design) workflow. But where this has really comes to the fore is with the simultaneous emergence of serverless infrastructure.
API consumption as part of business workflow design is now possible and affordable because all of these consumption workflows only need to be spun up and computed as needed. That means less linear and cyclical models will need to be developed and instead, multi-channel pathways that run simultaneously can be created and managed at once. For now, API consumption is reimagining the API lifecycle, but next, serverless will be taking this to a whole new realm of possibilities.
Feature image via Postman.