Vaideeswaran Ganesan writes:
I actually want to avoid get, post, put, 2xx, 4xx codes in the client portions of the code.
I think this goal is too high-level for the standard library. I don't know what you expect on the other side, but in an application I work on it matters whether you're using GET or POST, whether you use POST, PUT, or PATCH in the application's REST API. I don't see using something other than those identifiers in the API, because they have well-defined semantics. If OpenAPI uses different identifiers, I would very likely avoid using it. The (apparent) mapping of AttributeError to "not 200" is pretty questionable, too. I could see providing an IntEnum for the standard status codes, but avoiding them entirely and instead catching a Python Error that doesn't seem to have an obvious mapping to the API's statuses doesn't seem like a great idea. If you conceal the status codes, what is the client supposed to do with an application-specific code, or a new code added to the standard?
(I don't think it's pythonic).
Not clear what you mean by that. Saying what you mean in the established language for those semantics seems Pythonic enough to me.
And Fastapi seems to have them exactly the same. Look at how the code looks when you are using FastAPI and with my OpenAPI Native Bindings - below:
Not gonna fix the garbage text/plain from your mail client, but even so
=============== [Code using FastAPI] def test_create_item(): response = client.post( "/items/", headers={ "X-Token": "coneofsilence"}, json={"id": "foobar", "title": "Foo Bar", "description": "The Foo Barters"}, ) assert response.status_code == 200 assert response.json() == { "id": "foobar", "title": "Foo Bar", "description": "The Foo Barters", }.
looks more useful than
=============== [Code using pyopenapi - my proposal] def test_create_item(): client = client('host', creds).connect('/') try: assert client.items.id == "foobar" assert client.items.title == "Foo Bar" assert client.items.description == "The Foo Barters" except AttributeError: print("Items does not exist!")
to me. Also, the two examples seem to have very different semantics. The first not only POSTs the items but also presents some sort of auxiliary data (the X-Token). The second appears to be implicitly a fetch despite the function name, but whether it's a GET or a POST with implicitly specified content, and what's in "creds" is quite unclear; I guess that's probably the X-Token again, but whether that is going to be the X-Token HTTP header or part of the POST content is anybody's guess. If you want to make a convincing argument you're going to have to provide better examples and more discussion of them.