prefer the 'summary' for naming methods

[SiKing]

When importing Swagger, currently each resource is named using the path. Further, the path is already displayed in SoapUI following the resource name in square brackets.
It would be better to use use the "summary" from the Swagger to name each resource.

This would be the same behaviour as what Postman does, which ends up with a little cleaner project.

[olensmar]

The summary is in the Swagger definition specified at the operation level so one can have different summaries for GET/POST/PUT/etc methods under the same resource; these correspond to methods in SoapUI - which are all under a single resource - so I'm not sure what summary we would use to name the resource itself. (PostMan "flattens" this structure instead of maintaining the path/method hierarchy).

Currently each created method is named using the operationId - but we can improve it to fall back to the summary if no operationId is provided - and we can name the resource with the summary if it only contains one operation? Thoughts?

[SiKing]

At my client we are going through upgrading our stuff from Swagger 1 to 2. I was tasked with verifying that everything looks "acceptable". I tried importing our Swagger into both Postman and SoapUI.
I am not sure what you mean by 'PostMan "flattens" this structure'. The Postman import ended up being much "cleaner", using the summary for each method name, and everything was organized better in a hierarchical manner.
In SoapUI, I ended up with what I would call a completely "flat structure". There was no attempt to group together methods that have same path (GET, POST, PUT, etc.) and all resources were just named by the path.
Postman is by no means perfect! But after the import, the amount of massage I would have to do to get it to a usable state was less for PostMan than for the SoapUI import.

I could provide the Swagger resource, but not in a public forum. Send me a mail if you'd like. We worked together on the API Testing Dojo. ;)

[olensmar]

Thanks!

I guess this depends on how your Swagger definition was created during the conversion from 1.2 - Currently the Swagger importer will create:

• one resource for each path in the definition, and under that:
  • one method for each operation (get,post,etc), and under that:
    • one request for each consumes value (or a default request if there is no consumes)

Since the summary in Swagger is at the operation level that would correspond to the method level in SoapUI - not the resource level (which can contain multiple methods/operations) - so I don't see how we would use the summary to name the resource in the situation where the resource has multiple methods...

I really appreciate your input - how should we handle this?

[SiKing]

I am not familiar enough with the Swagger (standard?) to know what all can be done in it.

I think the "grouping" algorithm in Postman is little better. It appears that Postman groups the methods by the first part of the path. Whereas in SoapUI, I did not see any attempt at grouping things.