-
Notifications
You must be signed in to change notification settings - Fork 7
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
Move towards JSON API standard for responses #18
base: master
Are you sure you want to change the base?
Conversation
using models from optimade python tools
@chrisjsewell I've explicitly excluded the vendored |
Codecov Report
@@ Coverage Diff @@
## master #18 +/- ##
==========================================
+ Coverage 88.88% 89.75% +0.86%
==========================================
Files 6 9 +3
Lines 153 205 +52
==========================================
+ Hits 136 184 +48
- Misses 17 21 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
We'll also need to decide whether to make the response fully JSON API compliant - would be straightforward but would definitely mean having to edit all response processing of existing clients (since the data moves from |
So I imagine you want something like this in the mypy.ini:
(it doesn't matter that you've excluded it, because it follows imports) |
Well I guess if we are going to make breaking changes, lets not be shy about it lol. I think it is better if possible to have one major change that clients can deal with in one go, rather than multiple stages of changes |
@@ -51,6 +52,7 @@ repos: | |||
- fastapi~=0.65.1 | |||
- uvicorn[standard]>=0.12.0,<0.14.0 | |||
- pydantic~=1.8.2 | |||
- pydantic-jsonapi==0.11.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why pinned to a single version?
""" | ||
# pylint: disable=too-few-public-methods | ||
|
||
from .entities import * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Err, I'm not really a fan of *
imports, I think explicit is better. Like we've seen with aiida-core, you can end up with things like sub-classes clobbering namespaces.
I'm open to a discussion on what the best practice is though (is there some PEP that advocates for this?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @ltalirz, looks like a good standardised approach 👌
just a few minor questions
Start moving towards the JSON API standard for responses of the API.
In particular, the actual data is now returned in a
data
field.We are not fully adopting the JSON API standard here just yet, since the responses of the aiida-core REST API are not fully compatible.
aiida-core REST API example:
How a JSON API conforming response would look like