Some Thoughts For The Coming Wave Of API Hubs, Garages, and Workbenches
06 Oct 2015
I've been getting demos of some pretty interesting new work spaces meant for API architects, and designers. Examples of this are API Garage, RepreZen API Studio, and the recent SwaggerHub. These are just some of the API life-cycle solutions I'm seeing emerge recently, where companies are trying to provide API design, development, and deployment solutions in a single, tidy, work space.
Now that the API life-cycle has expanded beyond just API management, deployment, and design, into testing, monitoring, security, and beyond, I predict these types of API work-spaces that span multiple stops along the API life-cycle will become common place. To help prime the pump, and ensure there will be more viable products launched, I wanted to share a few thoughts on what these solution providers should consider as part of their offerings.
Here are some of my scribbles while drinking an IPA at my local bar:
- API Definitions - Speak Swagger, API Blueprint, Postman Collections, and other common API definition formats, and allow for the importing and exporting of them at every step.
- Provide APIs - Make sure you provide APIs to all the functionality available within the workspace -- paying the whole API thing forward.
- Consume APIs - Make sure you allow the consumption of APIs, from within the interface, either as part of http client, or add-ons.
- Plug-in Framework - Allow some sort of extensibility of the work space, allowing 3rd parties to augment the platform via plugins.
- Play Well With Others - Please play nice with other service providers, all of this works because of interoperability, and I should be able to use the services I need via my work space.
- Search - Provide a comprehensive search, allowing me to discovery across everything I do within a work space, via a comprehensive history
- Notebook - Give me a notebook for storing my work, draft APIs, and other items I gather through my work, allowing me to come back and re-use work from the past.
- Use Github - Make sure Github is a first class citizen within the workspace, allowing me to import, and publish all my work to Github -- think orchestration, not just import and publish.
- Non-Developer Friendly - Make sure tht the work space isn't just for developers, and anyone can come in and participate throughout the API life-cycle.
- Provide a HTTP Client - Make sure there is a built-in, or embeddable HTTP client, so get building one, partner with existing, or acquire one you like.
These are just a few of my thoughts as I received a demo of one API work space, and was reading about a couple of other new products. After scribbling these thoughts, I sat back, drank a another pint of IPA, and contemplated the role of these types of work spaces in the future of the API industry. I predict there will be a wave of these API work spaces emerge in coming months, providing their own take on exactly what the API life-cycle looks like, and want to help developers standardize and be successful.
I am looking forward to playing with all the new work space, and hoping there will be at least one to emerge that suits my unique needs as the API Evangelist. I will need all of the elements listed above, or I probably won't be working in there full-time.