In that framework your serializers are by default auto-generated from your model classes; this is convenient to get started, just like Django itself.
Types for Python HTTP APIs
41–50 of 55 posts
Re: Types for Python HTTP APIs
#42Earlier quoted context omitted.
Yeah I feel FastAPI will become the new Flask in a few years. The growth this year has been amazing. I wish I had started my project with it, but I am still using Flask. I found this nice extension though called Flask-Rebar that does a similar task with Marshmallow.
Yeah I feel FastAPI will become the new Flask in a few years. What else does it offers besides performance (switching to async is no free lunch)?
Re: Types for Python HTTP APIs
#43Earlier quoted context omitted.
Yeah I feel FastAPI will become the new Flask in a few years. What else does it offers besides performance (switching to async is no free lunch)?
I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me: - Integrates nicely with some existing libraries (Starlette, Pydantic) - Well documented - Auto-validation of endpoints from data models - Auto-generation of OpenAPI schemas from those models - Auto-serves live API docs from that schema - Easy definition of sync and async endpoints Again, it was just a tiny proof-o…
class CreatePostInput(InputClass):
text: str
user_id: str
...
@handler.post('/post')
def create_post(input: CreatePostInput):
...Re: Types for Python HTTP APIs
#44I would dare anyone come up with even 100 for the Instagram app.
Re: Types for Python HTTP APIs
#45Earlier quoted context omitted.
Can you elaborate on this? I’d love to actually use types in Python.
Python 3 has optional static typing: https://docs.python.org/3/library/typing.html https://realpython.com/python-type-checking/
def f(x: int):
x = "str"
f(42)Re: Types for Python HTTP APIs
#46Earlier quoted context omitted.
I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me: - Integrates nicely with some existing libraries (Starlette, Pydantic) - Well documented - Auto-validation of endpoints from data models - Auto-generation of OpenAPI schemas from those models - Auto-serves live API docs from that schema - Easy definition of sync and async endpoints Again, it was just a tiny proof-o…
> - Auto-generation of OpenAPI schemas from those models Is there a package that can do a reverse? Can I give it an OpenAPI spec and get a code stump going?
Solves most of the problems for that.
Re: Types for Python HTTP APIs
#47Been doing this before the typing module was released, using hug: http://www.hug.rest/ FastAPI has a lot of advantages at this point for someone looking to do the same: https://github.com/tiangolo/fastapi hug has some catching up to do, some of it just because it got in so early (It needs to be updated to be compatible with mypy and the types defined typing.py!) in any case using typing on API endpoints - independent…
Re: Types for Python HTTP APIs
#48Earlier quoted context omitted.
I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me: - Integrates nicely with some existing libraries (Starlette, Pydantic) - Well documented - Auto-validation of endpoints from data models - Auto-generation of OpenAPI schemas from those models - Auto-serves live API docs from that schema - Easy definition of sync and async endpoints Again, it was just a tiny proof-o…
> - Auto-generation of OpenAPI schemas from those models Is there a package that can do a reverse? Can I give it an OpenAPI spec and get a code stump going?
Connexion [1] is built on top on Flask and does routing and validation based on an OpenAPI spec.
I've recently started developing Pyotr [2], which does the same only based on ASGI and Starlette. It also includes a client module.
[0] https://openapi-generator.tech/
Re: Types for Python HTTP APIs
#49But if you have a relatively clear idea of what your API should look like, there are great benefits to be gained by providing the specification first. This way, you don't need for the API to be implemented to start developing the clients, even by completely unrelated teams. Second, your spec will already include your routing and validation rules, and there is no need to manually specify e.g. Pydantic models.
I recently wrote a PoC of a framework [0] that uses the OpenAPI spec to easily implement a REST(ful) API; in a nutshell, you need to implement endpoint functions that correspond to the spec's `operationId` names, and it will automatically route a request to the right endpoint. It is fully ASGI compliant and as has a bonus client module, which allows you to do the requests.