Build a Business Workflow
A standardized API lifecycle can be applied to the design, development, and usage of API business workflows that are defined as machine readable collections which can be automated using monitors and CI/CD pipelines. Postman collections provide a versatile approach to defining multiple individual API requests that include authentication, parameters, headers, and other details, then organize into folders and specific sequences. Providing a format for defining, documenting, but then also executing common business workflows across many internal, partner, or external APIs. Something becomes endlessly useful when managed as part of a well defined lifecycle, equipping developers with what they need to define and design the workflows, but also maintain them, execute them, and use them to automate a variety of business tasks that exist in their worlds.
Ensuring that operations supporting an API is properly defined, as well as what is needed to properly design and bring an API to life. A little planning and organization at this step of an APIs journey can go a long way towards ensuring the overall health and velocity of an API, and the applications that depend on this internal, partner, or public API.
Any API you are looking to develop should have a known location where any stakeholder can get up to speed on what is happening with the development and operation of an API. Postman team workspaces provide a single location to publish APIs, documentation, mock servers, tests, and other artifacts, providing a known location that is discoverable across teams. Establishing early on a place for teams to engage around the design, development, and operation of an API, that makes the API lifecycle observable by default. Team workspaces are only accessible internally to your team members who have an account under your designated organizational Postman team, making it available across search, and via workspace browsing for your team to discover and begin collaborating and working across APIs being developed within each workspace.
Having a formal process and approach to designing an API helps establish consistency and the precision of APIs in production, ensuring that APIs are developed using common patterns across an industry, and within an organization, establishing known practices for shaping the surface area and behaviors of APIs that applications are depending upon.
A workflow collection allows multiple API requests to be organized into a specific business workflow that can be executed manually, scheduled via a monitor, or triggered as part of a CI/CD pipeline. Workflow collections organize requests made to many different APIs into a single sharable, portable, and executable workflow that anyone can run. Allowing developers to automate and orchestrate each request in a workflow using pre-request and pos-request scripts, and leverage environments for common variables, secrets, and even to store data generated from the run of each workflow collection. Providing a very powerful low-code as well as no-code solution for accomplishing simple or advanced business workflows across many different internal, partner, and 3rd party APIs.
Having complete, accurate, and easy to follow document is essential for all APIs, helping alleviate the number one pain point for API consumers when it comes to onboarding with an API, as well as expanding the number of API paths an application puts to work, making API documentation one of the most important areas of the API lifecycle.
Workflow collections come with documentation by default. Every request and response that gets defined will automatically include the ability to provide summaries and descriptions to help consumers understand what happens with each step. However, it is up to the workflow collection developer and owner to ensure that the overall workflow is adequately described, as well as how rich the summaries and descriptions are for each request or step of the workflow, as well as what can be expected when the workflow is executed manually, via monitor, or as part of a pipeline. Workflow documentation ensures that all automation across API operations has the potential to be properly documented, so that when there is turnover in staff that all elements of automation possess all the details regarding their operation by default.
A test-driven API lifecycle ensures that each API accomplishes the intended purpose it was developed for, providing manual and automated ways to ensure an API hasn't changed unexpectedly, is as performant as required, and meets the security expectations of everyone involved, helping establish a high quality of service consistently across all APIs.
Workflow collection tend to utilize pre-request and post-requests scripting for the automation before and after each individual request is executed, but because post-request scripts are also often used for API testing and possess a rich assertion library, they can also be used to test the outcomes and results of each business workflow defined as a collection. Allowing for the testing of each individual step of a workflow, iteration, as well as the overall outcomes of the workflow run, allowing for not just the testing of individual APIs, but of entire business workflows needed to power operations. Taking testing to a whole other level, allowing testing to be closer aligned to actual business objectives, and not just individual technical components of IT operations.
All tests applied to an API should be monitored on a logical schedule and from relevant geographic regions, monitoring that APIs aren't breaking their contract, falling below their agreed upon service level agreement (SLA), or becoming a security risk, helping automate the quality of service across APIs in a way that allows teams to be as productive as possible.
Workflow Testing Monitor
Each workflow collection can have one or more monitors setup to schedule the run of the workflow at a specific time using a specific environment. Allowing any business workflow to be automated and run on a regular schedule with each execution potentially reporting and saving the results of it’s run, as well as any data that was collected as part of it’s execution. Putting the automation and orchestration in the low-code / no-code world, allowing specific business workflows to be run whenever they are needed and containing the proper testing to ensure that everything executed as expected, and the desired business outcomes were achieved. Allowing for the automation of anything defined as a collection, which is defined by any capability that can be defined as an API–leaving for a pretty wide world of automation possibilities.
This blueprint looks at how you can approach the development and operation of API-driven workflows using a well defined API lifecycle. Each element within this blueprint works to provide a simple overview of what is involved across the entire life of an API, with more detail present on the detail page for each element (if you are viewing this on the API lifecycle project site). If you are reading this via a PDF or printed version you can visit the landing page for this blueprint to access more information and view specific actions you might possibly consider taking as part of applying each element of this proposed lifecycle within your own operations. This blueprint is a living document and will continue to evolve and be added to over time based upon feedback from readers. If you have any questions, feedback, or feel like there is more information you need, feel free to jump on the Github discussion for this blueprint, or any of the individual elements present--the value this blueprint provides is actively defined by the feedback community members like you.