René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add object-oriented client option","articleBody":"First of all, thank you for this great project, the code is very nice and I think it really has a lot of potential.\r\n\r\n**Is your feature request related to a problem? Please describe.**\r\n\r\nAs mentioned in https://github.com/triaxtec/openapi-python-client/issues/171, the current approach arguably needs a little too much boilerplate that could be avoided by adding a more object oriented `Client`.\r\n\r\n**Describe the solution you'd like**\r\n\r\n* Add two new client interfaces, `SyncClient` and `AsyncClient` that would wrap the currently generated tag packages in objects, and expose them as properties.\r\n\r\nWith that approach, a developer could call an endpoint with as little code as:\r\n```python\r\nfrom petstore_client import SyncPetstoreClient  # Named after the spec title, nicer if you import several auto-generated clients\r\nclient = SyncPetstoreClient(\"http://mypetstore\")\r\npets = client.pets.list_pets()\r\n```\r\n\r\n* One issue is that we loose the ability to statically tell the user that some endpoint requires an `AuthenticatedClient` or not... Some thinking required here I guess.\r\n\r\n* Additionally, a default `base_url` could be provided through an environment variable named after the spec title, for instance: `SWAGGER_PETSTORE_BASE_URL`. It could be nice to prevent microservices from using different naming conventions.\r\n\r\nFor reference, my crude attempt at implementing those interfaces is available here: https://github.com/upciti/openapi-python-client/tree/feature/0-boilerplate-clients.\r\n","author":{"url":"https://github.com/fyhertz","@type":"Person","name":"fyhertz"},"datePublished":"2020-10-28T13:15:50.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/224/openapi-python-client/issues/224"}