It is converting the REST API syntax into language constructs. If such mapping doesn't exist - I agree with you that we probably should give flexibility to user. On the other hand, if such mapping exists and I strongly believe so - seeing several examples in web,  we should allow it.

Intent is to make a web interaction as if you're working with local function. This is very well known design pattern called Proxy. 

It also simplifies the programmer allowing same experience whether you are working with local or remote interfaces. 

I know we are used to one paradigm. But sometimes, we need to see if others also are applicable in relevant cases.

Given the examples I have seen (swagger, sushi),  we should see where this could be relevant.

On Sat, Aug 7, 2021, 13:14 Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
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.