Use optional operation.operation_id when generating client methods

[stephenknoth]

@davebelais - Thoughts on using the optional operationId property when generating client methods as part of oapi.client.Module.save(...)?

In this method: _iter_operation_method_declaration

Something like this..

        method_name: str = (
            f"{method}_{sob.utilities.property_name(operation.operation_id or path)}"
        ).rstrip("_")

Reason being - if you have a path like this: /entrants_event.aspx?did={event_id}

It can make for a pretty ugly looking method name: get_entrants_event_aspx_did_event_id

Whereas with the above substitution and openapi path definition:

paths:
  /entrants_event.aspx?did={event_id}:
    get:
      operationId: event_entrants

you can a resulting method name like: get_event_entrants. I think there could be other checks too, like if the operationId already contained (get|post|delete)_ etc to not include that as part of the method name so as to not repeat it.

Also, operationId has to be unique per the openapi 3.0.0 spec, so we'd need to keep track of which were already used when generating the source

[davebelais]

@stephenknoth - Yes, I think that should be fine. It would write clients which are incompatible with previous versions, however—so would require a major version bump. I had used operationId for model class names in version 0.x, but ran into too many scenarios where that introduced conflicts—but for client methods I can't think of any likely issues so long as operationId is used correctly :-).

[davebelais]

*it might be worth having a parameter/property for Model to determine whether operationId is used, in order to be able to utilize the latest version without breaking backwards-compatibility of a generated client.