Will there ever be sessions that give more info on building your own API structure? Working without a swagger to import from has been pretty difficult for me as every tutorial I find assumes I already have APIs ready to import.
There are a number of ways to test APIs that don't have a descriptor. The easiest would be to point to Endpoint URL: support.smartbear.com/readyapi/docs/soapui/creating.html#from-url If you're looking to build an API that doesn't exist, then we can assist on the ServiceV side to mock out an API: support.smartbear.com/readyapi/docs/servicev/create/from-resource-paths.html We are looking to add sessions that will give you more info on this in the future.
@@Smartbear Thanks for the reply, I've managed to figure it out in the end indeed. It' just been a bit of a struggle. My main issue was that just importing any endpoint, in a microservices context with many many microservices each having their own endpoints and many calls, it was becoming extremely hard to structure the endpoints. You can not group them in folders by microservice, you can't tag them or automatically sort them. I eventually ended up going with a parent/child structure where I would define them all in a hierarchic tree structure. It's been a big learning process though and refactoring the first attempts I made were a bit problematic since test requests were already tied to these defined services, trying to remove and regroup them would remove the test requests tied to them. I eventually ended up doing hackish things like copying all my tests to another project, then redefining and regrouping all my services, then importing all my tests again since then it automatically tries to find the endpoints and asks in a wizard to point at the ones where there isn't a clear match. I eventually ended up coming to a solution that works for me but it's definitely been the hardest part of my testing so far. Which is where the need for more tutorials on making and refactoring your own services without having a swagger comes from. Maybe it could be a feature some day in a future version of SoapUI to be able to group them in folders so users can make their own groups of API calls. Besides this bit of a struggle, SoapUI PRO has been an amazing product though.
@@kendemoor3281 Glad to hear that in the end, your API tests are working. During our continuous improvements and releases, we'll try and address many pain points that you referenced. Thanks again!
Can we load data to bigdata with help of soapui?
Will there ever be sessions that give more info on building your own API structure? Working without a swagger to import from has been pretty difficult for me as every tutorial I find assumes I already have APIs ready to import.
There are a number of ways to test APIs that don't have a descriptor. The easiest would be to point to Endpoint URL: support.smartbear.com/readyapi/docs/soapui/creating.html#from-url
If you're looking to build an API that doesn't exist, then we can assist on the ServiceV side to mock out an API: support.smartbear.com/readyapi/docs/servicev/create/from-resource-paths.html
We are looking to add sessions that will give you more info on this in the future.
@@Smartbear Thanks for the reply, I've managed to figure it out in the end indeed. It' just been a bit of a struggle.
My main issue was that just importing any endpoint, in a microservices context with many many microservices each having their own endpoints and many calls, it was becoming extremely hard to structure the endpoints. You can not group them in folders by microservice, you can't tag them or automatically sort them.
I eventually ended up going with a parent/child structure where I would define them all in a hierarchic tree structure.
It's been a big learning process though and refactoring the first attempts I made were a bit problematic since test requests were already tied to these defined services, trying to remove and regroup them would remove the test requests tied to them. I eventually ended up doing hackish things like copying all my tests to another project, then redefining and regrouping all my services, then importing all my tests again since then it automatically tries to find the endpoints and asks in a wizard to point at the ones where there isn't a clear match.
I eventually ended up coming to a solution that works for me but it's definitely been the hardest part of my testing so far. Which is where the need for more tutorials on making and refactoring your own services without having a swagger comes from.
Maybe it could be a feature some day in a future version of SoapUI to be able to group them in folders so users can make their own groups of API calls.
Besides this bit of a struggle, SoapUI PRO has been an amazing product though.
@@kendemoor3281 Glad to hear that in the end, your API tests are working. During our continuous improvements and releases, we'll try and address many pain points that you referenced. Thanks again!