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...@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.
>
>
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NAGCWEYIHPFDPEIN5SKU5EJEMVOLHZBO/
Code of Conduct: http://python.org/psf/codeofconduct/
