Closed jfinkels closed 8 years ago
This would supercede issue #193 and (the already implemented) #2.
The problem here would be that requests to /api/person/1/computers/3
won't have the include/exclude field rules.
Maybe a more complicated list configuration, like
# A list of three tuples: first the URL fragment, second the list of methods to allow,
# and third a list of fields to include.
relations = [
('computers', ['GET', 'POST'], ['id']),
('computers/<id>', ['GET', 'DELETE', 'PATCH'], ['id', 'make', 'model']),
('computers/<id>/accessories', ['GET'], None),
('friends', ['GET', 'POST'], ['id']),
('friends/<id>', ['GET', 'DELETE'], ['id', 'name', 'age'])
]
... or even more complex as there http://pythonhosted.org/dictalchemy
relations = [
('computers', ['GET', 'POST'], {'exclude': ['id']}),
('computers/<id>', ['GET', 'DELETE', 'PATCH'], {'include'=['id', 'make', 'model']}),
('computers/<id>/accessories', ['GET'], {'only': ['id', 'model']})
]
Remember the Zen of Python:
... Simple is better than complex. Complex is better than complicated. ...
Thx, i know ))
It may be nice to incorporate the conventions of dictalchemy. I will look into this.
@jfinkels it'd be interesting to see dictalchemy conventions work their way in
This is what I implemented (Though with a more explicit usage API) in https://github.com/jfinkels/flask-restless/pull/234. Though with much more flexibility in defining what happens at the endpoints.
We now only go to /api/person/1/parent
or /api/person/1/computers/2
and no further, with CRUD semantics governed by the JSON API protocol, so this is no longer relevant.
Create a more general framework that allows users to specify which relations will be accessible and at which endpoints. For example,
which should automatically allow requests like
POST /api/person/1/friends
. This will require a human hours-intensive rewrite of the code as it stands right now.