You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the CadastaSession class manages authentication and requests to the Cadasta Platform and the endpoints submodule allows users to not think about URLs. This is helpful but it still requires the users to have knowledge of RESTful interactions (e.g. use session.get() for reading and session.post() for creating).
I think it would be useful to create tooling to manage data at a higher level. This could look something like:
To model the relational nature of URLs between classes, I believe we would make a model class for each data type with a URL_TEMPLATE property (e.g. /organizations/{slug}). When instantiating related subclasses, we could replace the portions of URL_TEMPLATE that exist on the subclass with the populated URL from the parent class (e.g. /organizations/{slug}/projects/{slug} -> /organizations/my-org/projects/{slug} if we were looking at Organization.get(slug='my-org').Project). The API requests should be lazy to limit the amount of unnecessary requests (i.e. we don't actually want to query for Organization.get(slug='my-org') when we are running Organization.get(slug='my-org').Project.get(slug='my-proj').
The text was updated successfully, but these errors were encountered:
Already existing higher-level functionality such as session.upload_file() or session.get_csrf() should probably me moved to the higher-level interface class.
Currently, the
CadastaSession
class manages authentication and requests to the Cadasta Platform and theendpoints
submodule allows users to not think about URLs. This is helpful but it still requires the users to have knowledge of RESTful interactions (e.g. usesession.get()
for reading andsession.post()
for creating).I think it would be useful to create tooling to manage data at a higher level. This could look something like:
To model the relational nature of URLs between classes, I believe we would make a model class for each data type with a
URL_TEMPLATE
property (e.g./organizations/{slug}
). When instantiating related subclasses, we could replace the portions ofURL_TEMPLATE
that exist on the subclass with the populated URL from the parent class (e.g./organizations/{slug}/projects/{slug}
->/organizations/my-org/projects/{slug}
if we were looking atOrganization.get(slug='my-org').Project
). The API requests should be lazy to limit the amount of unnecessary requests (i.e. we don't actually want to query forOrganization.get(slug='my-org')
when we are runningOrganization.get(slug='my-org').Project.get(slug='my-proj')
.The text was updated successfully, but these errors were encountered: