Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON:API compliant API #149

Open
ghilesmeddour opened this issue Mar 5, 2022 · 2 comments
Open

JSON:API compliant API #149

ghilesmeddour opened this issue Mar 5, 2022 · 2 comments

Comments

@ghilesmeddour
Copy link

Hi @awtkns 👋

Thank you for this great library, really convenient and handy ❤️

For a couple of days I've been looking for a simple and clean way to build a JSON:API compliant API with FastAPI, but I did not find anything suitable.

This has already been discussed here and here. @tiangolo says that the support should be done by an external library, and it wouldn't really make sense to have built-in support in FastAPI for automatically generating JSON-API as FastAPI doesn't have any compromise about which DB or ORM (or similar) to use.

When I came across fastapi-crudrouter, I thought it might be the right place to support this (the lib already offers pagination, it would be a matter of offering also filtering, sorting, limiting and a compliant output format). What do you think?

@harshalchaudhari35
Copy link

has anyone already seen/mentioned this https://github.com/Zenor27/fastapi-rest-jsonapi ?

I believe above repo is using "marshmallow_jsonapi" under the hood to define the relationships in response schemas. Although, I'm not too sure how does this affect the serialization/de-serialization in terms of speed and performance. Might be an option to explore and possibly merge/cherry-pick the crudrouter into the repo or vice-versa.

@auvipy
Copy link

auvipy commented Apr 12, 2022

has anyone already seen/mentioned this https://github.com/Zenor27/fastapi-rest-jsonapi ?

I believe above repo is using "marshmallow_jsonapi" under the hood to define the relationships in response schemas. Although, I'm not too sure how does this affect the serialization/de-serialization in terms of speed and performance. Might be an option to explore and possibly merge/cherry-pick the crudrouter into the repo or vice-versa.

that would br super cool! will check it out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants