Proposal for Refactoring: connexion/connexion/resolver.py::RestyResolver

[oxbqkwwxfrqccwtg]

Description

A suggestion for upgrading the coding style of connexion/connexion/resolver.py::RestyResolver, whilst maintaining the logic.

I haven't tested the code yet, but it should work on CPython >= 3.5. I would generally consider 3.5 the minimum version, since it's the version implementing PEP 484, which is the basis for proper, standardized type annotations in Python.

I used this as an exercise for understanding the operation of the RestyResolver. I will implement a custom resolver for an application.

I'll create a pull request once i've implemented my custom resolver, since i will get to run the RestyResolver code by then.

Additional info:

#!/usr/bin/env python3
from typing import Union
from pathlib import Path
from logging import getLogger

from connexion.operations import OpenApiOperation, Swagger2Operation
from connexion.resolver import Resolver

log = getLogger().getChild(__name__)


def test_path_parameter(segment: str) -> bool:
    """
    """
    return (component[0] == "{" and component[-1] == "}")


class RestyResolver(Resolver):
    """functional clone of the connexion.resolver.RestyResolver class

    it's sassy to say, but this code is less straining to the eyes, as well as 
    to the little and big brain.
    """

    def __init__(
        self: 'RestyResolver',
        entrypoint: str,
        endpoint: str = 'search'
    ):
        """
        :param entrypoint: Default module name for operations

        :param endpoint: str
        """
        super().__init__()

        self.entrypoint = entrypoint

        self.endpoint = endpoint

    def resolve_operation_id(
        self: 'RestyResolver',
        operation: Union[OpenAPIOperation, Swagger2Operation]
    ) -> str:
        """Resolve operationId using REST semantics (whatever that means)

        :param operation: connexion operation prototype object
        """
        if operation.operation_id:

            return super().resolve_operation_id(operation)

        operation_path = Path(operation.path).segments

        resource_name = '.'.join(list(filter(
            test_path_parameter,
            operation_path
        ))).replace('-', '_')

        function_name = method.lower()

        if operation.method.lower() == 'get' and \
            resource_name and \
            not test_path_component(operation_path[-1]):

            function_name = self.endpoint

        controller_name = operation.router_controller \
            if operation.router_controller \
            else self.entrypoint

        if resource_name and not operation.router_controller:

            controller_name += f'.{resource_name}'

        return f"{controller_name}.{function_name}"

[oxbqkwwxfrqccwtg]

Why does GitHub automatically upvote my post in my name? That's kind of weird.

[oxbqkwwxfrqccwtg]

Again...

[oxbqkwwxfrqccwtg]

I will close this discussion.

I've decided upon ditching Connexion in favour of a custom WSGI application. Neither Flask, nor Werkzeug is required and the Connexion/Flask app initialisation is too heavy for my use-case, where i just need an URL router, and JSON schema validator based upon an OpenAPI spec.

I wholeheartedly agree with a Specification-first approach, but (in my opinion) the way Flask is structured it counteracts to the lightweightness of WSGI. I mean this in regards to run-once process execution, and co-process execution, where a middleware, or adapter WSGI application should both be optimized for, since it can't anticipate what the terminal/target WSGI application is required to be optimized for (interpretation of PEP 333). With Flask however (which i consider a WSGI adapter), i only see optimizations for co-process execution. Optimizing Flask apps for Public Cloud functions (e.g. AWS Lambda, Azure Functions) is difficult, which is sad, because WSGI is a very nice CGI for said stuff.

Thank you.