I created a rudimentary API structure on top of the existing API library (Django's REST framework).
It should now include ViewSets (which enable easily accessible GET requests for all the database objects -- with a recursive tracing of all child relations down 3 levels, defined in SESHAT_API_DEPTH (in seshat.apps.seshat_api.serializers.py -- we may want to move this into the settings file instead)
All of the URLs are registered using the REST framework's DefaultRouter in seshat.apps.seshat_api.urls.py. The file's imports are split up by app, to make it more readable. It has also been formatted with black.
The API should be accessible at /api/ (e.g. http://localhost:8000/api/) and then all access points should be divided into respective apps (e.g. http://localhost:8000/api/core/, http://localhost:8000/api/crisisdb/, etc)
All (or at least almost all of them?) ViewSet have two Mixins added -- MixinSeshatAPISerializer, MixinSeshatAPIAuth. Those are defined in seshat.apps.seshat_api.views._mixins.py.
The MixinSeshatAPISerializer is used to automatically set the serializer_class of the ViewSet to the GeneralSerializer defined in the seshat.apps.seshat_api.serializers.py.
The MixinSeshatAPIAuth is used to automatically set the permission_classes of the ViewSet to the ones defined in a provided permissions_dict object (or reverting, by default to STANDARD_API_AUTHENTICATION which defines that HEAD, OPTION, and GET operations should be allowed for all, but any other methods are only open to authenticated users. You find STANDARD_API_AUTHENTICATION in seshat.apps.seshat_api.views._mixins.py. From what I've seen, we might want to make the authentication a bit more diversified (i.e. only allow POST, PUT for editors, RAs, etc...) We will need to discuss in a meeting.
Note: I have now built a Python-flavoured way of connecting up to the API to programmatically interact with the models:
I created a rudimentary API structure on top of the existing API library (Django's REST framework).
It should now include ViewSets (which enable easily accessible GET requests for all the database objects -- with a recursive tracing of all child relations down 3 levels, defined in
SESHAT_API_DEPTH(inseshat.apps.seshat_api.serializers.py-- we may want to move this into the settings file instead)All of the URLs are registered using the REST framework's DefaultRouter in
seshat.apps.seshat_api.urls.py. The file's imports are split up by app, to make it more readable. It has also been formatted with black.The API should be accessible at
/api/(e.g.http://localhost:8000/api/) and then all access points should be divided into respective apps (e.g.http://localhost:8000/api/core/,http://localhost:8000/api/crisisdb/, etc)All (or at least almost all of them?) ViewSet have two Mixins added --
MixinSeshatAPISerializer,MixinSeshatAPIAuth. Those are defined inseshat.apps.seshat_api.views._mixins.py.MixinSeshatAPISerializeris used to automatically set theserializer_classof the ViewSet to theGeneralSerializerdefined in theseshat.apps.seshat_api.serializers.py.MixinSeshatAPIAuthis used to automatically set the permission_classes of the ViewSet to the ones defined in a providedpermissions_dictobject (or reverting, by default toSTANDARD_API_AUTHENTICATIONwhich defines that HEAD, OPTION, and GET operations should be allowed for all, but any other methods are only open to authenticated users. You findSTANDARD_API_AUTHENTICATIONinseshat.apps.seshat_api.views._mixins.py. From what I've seen, we might want to make the authentication a bit more diversified (i.e. only allow POST, PUT for editors, RAs, etc...) We will need to discuss in a meeting.Note: I have now built a Python-flavoured way of connecting up to the API to programmatically interact with the models:
https://github.com/Seshat-Global-History-Databank/seshat_api