Postman is one of the most famous tools that developers are currently using for API development and testing. We highly recommend you peruse through the application at least once to understand its value.
This article documents how Turtlemint has been using Postman across teams in different locations to collaborate on development. Here is a website by Postman where they talk about what API collaboration is:
This should help you get a brief understanding of what Postman is and its basic use cases. Let us dive further into how we use it at Turtlemint.
Workspaces
At Turtlemint, we use multiple workspaces for different teams. These workspaces are a shared context for building and consuming APIs. You can find more details about them below
With roles and permissions being introduced by Postman, managing the access that teams have on their workspaces is also very helpful. This way, it’s easier to find APIs across the team.
Collections
Collections are groups of related requests and are the primary building block for all of Postman’s features. At Turtlemint, we have collections for each feature that we release. These are stored in their respective workspaces.
Documentation
Simple basic documentation of your API is automatically generated by Postman across the different requests in your collection. With every update to our API, the documentation automatically gets updated. We can easily publish these documents on a public site which can then simply be shared across the team.
At Turtlemint, we interact with multiple third-party clients and a backend developer cannot always be present to distill and share details of the different sorts of variables required and discuss the multiple use cases. In that case, API documentation comes in really handy.
Mock Servers
Mock Servers are for fast API integration. Delays on front-end or back-end make it difficult for dependent teams to complete their work efficiently. So without waiting for the back-end, we create a mock server and simulate each endpoint and its corresponding responses in the collection. This essentially means that workflow is not impacted due to a hold up at either end.
At Turtlemint, we interact with multiple third-party clients and these mock servers are also a great way for us to be able to provide simulated endpoints with which they can test the expected behavior across what they get.
REST & SOAP Requests
We work with many clients who work on both REST and SOAP. Postman is an effective API environment through which we can test and work with both REST API endpoints as well as SOAP endpoints.
Environments
We run APIs on multiple environments and provide different environments to our third-party clients as well. To easily handle switching between them, we make use of the environment in Postman to switch contexts and access the APIs
Future Endeavors
We intend on looking at implementing a few of the below features into our Postman workflow in the future.
API Test Script
We would like to look at working with API test scripts inbuilt to Postman to automate parts of our CI process.
Collection Runner and Newman
The above test scripts would be added to our CI pipeline by means of Newman and collection running to help enable a better backend driven CI pipeline.
OpenAPI Specification
Moving to a more standard API specification document based on which we build APIs in the company is a larger change and something that will take time. This is something we are exploring and look to implement in the near future.
Postman allows us to easily build APIs by means of OpenAPI Specification. Their new API workflow also allows us to manage all documentation, mock servers, and environments in a single interface.
The above post briefly mentions the Postman features that we at Turtlemint use. To better understand the features do go through the excellent documentation that Postman provides.
Excited to work with us? Knock at knock.knock@turtlemint.com for full-time roles and internship@turtlemint.com for internships.
