-
Notifications
You must be signed in to change notification settings - Fork 21
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
Serializer #19
Serializer #19
Conversation
ff54e76
to
b4dd095
Compare
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.
Let's talk tomorrow about how we want to procede with these PRs that are incremental/experimental. There are a lot of things that we know we will revisit, so it's hard to tell what we are settling...
It's mergeable if we agree to revisit a lot of aspects... 🤷
Rebasing and merging to get everything together. Once we do, it will be easier to know what to change/what is missing. |
2520d40
to
aa2e05b
Compare
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.
Approving just to get things moving.
Requires #16
Closes #15 - Many record/invenio specific things have been moved to
invenio-resources
. See more at inveniosoftware/invenio-records-resources#8.Closes #4 - The resource class does not
abort
anymore. It returns the error code. How to treat it properlly needs to be addressed in #9 (see more below).Errors and serialization
Note that the default resource returns a 405 code with no content and then the views call
make_response
by default. The default views are made to work with the resource test case (A.K.A. How would a user create an API with this). However, changes in this area are needed to:1- Support the behaviour of the default resource, i.e. return a 405 forbidden error.
2- Do the distinction from error and successful response somewhere. Could we benefit from some other abstraction present in Flask/Other library?
This questions will and the whole error serialization will be treated separatelly in #3
Resources file hierarchy
The
resource.py
currently contains theResource
, theCollectionResource
, theSingletonResource
and theResourceConfig
classes. Should they be separated into different files? If yes:resources
folder?views
folder?The answer will depend from and be treated in #18
Naming 🎊
The
SerializerMixin
uses the wordobject
, which is reserved. Any suggestions for a change?