HTTP APIs that operate in the cloud, but also APIs that are on-premise or are sandboxed all provide opportunities for developers to bring the value generated by APIs home to where they already work. The concept of what an API workspace os will vary from industry to industry, and is something that is shaped by how teams already do their work, but also each wave of API service provider to come long. While profiling the operations of leading API producers, we are always keeping an eye out for what the most common workspaces are, as expressed by API producers in support of their consumers.
- Git - Utilizing public or private Git organizations and repositories to work.
- Postman - Leveraging public, private, or partner Postman workspaces.
- IDE - Making available locally in integrated development environments.
- CLI - Making available locally on our machine using command line interfaces.
- Notebooks - Using Jupyter notebooks to provide guides for consumers.
Each of these workspaces will have a slightly different set of constraints for what they can store, and what the engagement with users are. Some of them are definitely targeting engineers, but others are something that support, sales, and product managers will be able to work with. All of these approaches are used by leading API producers, and are available via portals alongside documentation, SDKs, and other resources. This is just a look at the workspaces used by API producers, and future of this research will look more into what actually goes into these workspaces, and analytics that can be used to measure engagement.
