deoma03 Good point. I thought about this approach as well.
The concerns I had when arguing against myself were:
- The potential to create an unmanageable VSI. If one assumes each WSDL has 1 operation, the resulting VSI has 500 potentially different operations and signatures. Most WSDLs have more than one so it could be really large.
- Depending on actual response payload size, the resulting VSI might be difficult to edit in Workstation
- The single threading effect... The notion of multiple service developers each working on the same service simultaneously is lost.
- If the service is deployed in a functional VSE, TPS throttling might create a response bottleneck resulting in HTTP timeouts at the consumer(s). Would need to know more about how these APIs are accessed.
- It likely destroys the notion of using a base path in the VSM. I am always guarded about using a base path of /
- What happens if some of the services are HTTPS and others are HTTP. One VSM cannot support both HTTP and HTTPS on the same endpoint port. Matter of fact, although two VSMs could share one VSI, I don't think an HTTP and HTTPS service can coexist on the same port -- could be mistaken.
What I have not seen is a REST API where you can send the WSDL as a ZIP file and have DevTest build a service.
I created a Virtual Service that accepts a Swagger document as input, makes the REST API calls to build a service, and responds to the consumer with the Virtual Service information. However, the number and sequence of API calls necessary to do this were a bit tricky to implement.
I submitted feedback to the engineering team about simplifying the API to a single call -- perhaps this API is now available.