ruODK support for OData entity endpoints - naming?

Development
1

Hi,

The last piece of adding entity support to ruODK are the OData endpoints.

Quick ping to @LN and @Lindsay_Stevens_Au - what do you think of the following naming scheme:

  • Service Document GET /v1/projects/{projectId}/datasets/{name}.svc odata_entitylist_service_get
  • Metadata Document
    GET /v1/projects/{projectId}/datasets/{name}.svc/$metadata odata_entitylist_metadata_get
  • Data Document
    GET /v1/projects/{projectId}/datasets/{name}.svc/Entities odata_entitylist_data_get

Naming considerations:

  • This naming mirrors the existing OData functions odata_{service, metadata,submission}_get and distinguishes itself through the _entitylist_ infix.
  • I'm using entitylist instead of dataset following @LN's prior advice.
  • I've tentatively kept the _get to clarify the used HTTP verb but it feels a bit verbose. Will Central ever get other HTTP methods for the OData endpoints like to modify data?
2 Likes
2

Sorry I missed this, @Florian_May! I see @Lindsay_Stevens_Au gave a :+1: and I generally this all sounds good.

There isn't much of an analogy to make with pyodk. Currently it only exposes the data document through entities.get_table: https://getodk.github.io/pyodk/entities/#pyodk._endpoints.entities.EntityService.get_table

Users then can put the data in something like pandas which does a pretty good job of inferring types. We haven't yet had a request to provide a typed structure as I think you do with tibbles.

I don't think so. The only situation in which I could see us considering it is if Excel or some other tool that commonly uses OData got a great, generic editing experience.

1 Like