Possibility of friendly operation id names in published OpenApi Specs

[thulani]

Possibility of friendly operation id names in published OpenApi Specs

The current operation ids names are not very human readable and in particular are not friendly to client generation tools like nswag studio that use operation ids to generate method names.

Operation ids like get-/crm/v3/objects/deals/{dealId}_getById result in names that are either invalid code or in cases where they are, they are a mouthful to read and have a naming syntaxt that does not have the best order.

Can this possibly be cleaned to have operation ids like getDealById, getDealAssociationsById?

Thanks

[thulani]

Seeing this was merged, here is another set of issues I have discovered with the published OpenAPI specs.

Some API have discrepencancies on the versioning. For example below, notice how some endpoints show a v4 (which from my tests seems like it is not published yet as those do not work) and correctly shows v3 in the operation id.

Unfortanately due to the reality of stumbling upon so many issues we have had to ditch attempts to auto generate .net clients from these specs and create them manually. The good news though, is the APIs are highly standardized so in most cases just a different route same input/output, good job on that part!

[thulani]

There are some issues with the forms API https://api.hubspot.com/api-catalog-public/v1/apis/marketing/v3/forms

1. Cyclic dependencies in the models that cause StackOverflow exceptions in Nswag Studio
2. Invalid return type for a 204 on one of the operations

Here are the discovered cyclic dependencies

HubSportFormDefinition <-> FormDefinitionBase

HubSportFormDefinitionCreateRequest <-> FormDefinitionCreateRequestBase

Here is the discovered invalid 204 response
All other HubSpot APIs correctly handle this with an empty response

These issues breaks automation tools for creating API clients like nswag studio.