We want some regulatory control to understand who is reading our documentation in the space where we are active. It would be interesting to see who is looking for our API documentation, so that would be one way to understand the users. If it supports public API documentation, it's public. You never know who is likely to use it. There are other smaller things like tagging APIs and various other details. The workflow for editing to offer OpenAPI is not as rich as we would like, so we did the editing with other tools. Additionally, you cannot include additional pages explaining certain workflows you can do with the API. These additional content pages would enhance the OpenAPI specification for the API. So these things are not significant, but they can make a difference when you don't have them.
SwaggerHub lacks in terms of integrations. They have APIs integrated, and they also have some connectors, but they don't have integration with many of the things that we use. For example, for connecting with SVN, we had to implement external scripts. So, they should work on the integration because currently, we have to work on the integration with our DevOps, continuous delivery, or continuous deployment. It would be great if these integrations are built-in. Mainly, we would like it to integrate with SVN and Jira.
The review process should be improved. There seem to be some gaps, at least for us, for the editing part because we would like to have a full request review mechanism. They support some comments, but it is really hard to manage those comments. We would like to use the full request. Therefore, we are now looking to integrate with repositories. It has integration with Bitbucket and GitHub, but we have some internal constraints, and we need to move some of the repositories to GitHub. Our source code is on-premise in Bitbucket, and it was a bit of a problem for us to integrate. Now we are transitioning our repositories to GitHub, and hopefully, we can enable the integration. This will probably solve the problem with the review and approval. Its customization should also be improved. There are limitations around the support for the developer portal. There should be more customization options for the website that you can use as a developer portal. Currently, it has only Swagger UI with minimal customization. You cannot actually add additional pages and documentation for explaining concepts and general things. That's why we have started to look around to see what other tools are doing. They should also allow tagging on the API. We would like to add some tagging on the API to reflect certain things. Currently, any metadata that you would like to have has to be a part of the spec. You cannot do anything else. It should also have support for Open API 3.1, which was released at the beginning of the year. It would be great to be able to switch to that.
SwaggerHub is an integrated API Development platform, built for teams, that brings the core capabilities of the Swagger framework to design, build, document and deploy APIs. SwaggerHub enables development teams to collaborate and coordinate the entire lifecycle of an API with the flexibility to integrate with the toolset of your choice.
We have to use additional tools to test APIs.
We want some regulatory control to understand who is reading our documentation in the space where we are active. It would be interesting to see who is looking for our API documentation, so that would be one way to understand the users. If it supports public API documentation, it's public. You never know who is likely to use it. There are other smaller things like tagging APIs and various other details. The workflow for editing to offer OpenAPI is not as rich as we would like, so we did the editing with other tools. Additionally, you cannot include additional pages explaining certain workflows you can do with the API. These additional content pages would enhance the OpenAPI specification for the API. So these things are not significant, but they can make a difference when you don't have them.
The solution could be more intuitive compared to Postman. They should improve this particular area.
SwaggerHub could be improved with better integration for tools.
SwaggerHub lacks in terms of integrations. They have APIs integrated, and they also have some connectors, but they don't have integration with many of the things that we use. For example, for connecting with SVN, we had to implement external scripts. So, they should work on the integration because currently, we have to work on the integration with our DevOps, continuous delivery, or continuous deployment. It would be great if these integrations are built-in. Mainly, we would like it to integrate with SVN and Jira.
The review process should be improved. There seem to be some gaps, at least for us, for the editing part because we would like to have a full request review mechanism. They support some comments, but it is really hard to manage those comments. We would like to use the full request. Therefore, we are now looking to integrate with repositories. It has integration with Bitbucket and GitHub, but we have some internal constraints, and we need to move some of the repositories to GitHub. Our source code is on-premise in Bitbucket, and it was a bit of a problem for us to integrate. Now we are transitioning our repositories to GitHub, and hopefully, we can enable the integration. This will probably solve the problem with the review and approval. Its customization should also be improved. There are limitations around the support for the developer portal. There should be more customization options for the website that you can use as a developer portal. Currently, it has only Swagger UI with minimal customization. You cannot actually add additional pages and documentation for explaining concepts and general things. That's why we have started to look around to see what other tools are doing. They should also allow tagging on the API. We would like to add some tagging on the API to reflect certain things. Currently, any metadata that you would like to have has to be a part of the spec. You cannot do anything else. It should also have support for Open API 3.1, which was released at the beginning of the year. It would be great to be able to switch to that.
More integration and usability with the cloud microservices would be nice. Azure and GCP — there are multiple platforms we could talk about.