Provider and Policy GET data payloads vs. other data payloads

[thekaveman]

Issue

Provider defines the data payload under the data top-level key, with an endpoint-specific key that holds the array of items:

{
    "version": "2.0.0",
    "data": {
        "vehicles": [
             // vehicle objects here
         ]
     }
}

This differs from e.g. Agency and Geographies, which define their GET payloads as top-level keys on their own, without the addition of the data layer:

{
    "version": "2.0.0",
    "vehicles": [
        // vehicle objects here
     ]
}

Suggestion

Align Provider with the other APIs, by removing the additional data layer in the response payload, and returning the actual data items as a top-level key, like in Agency and Geographies.

[schnuerle]

Is Provider the only one like this? What about Metrics, Policy, Jurisdiction? If provider is the only one using data I'd say we should change it too.

cc @marie-x

[marie-x]

Agree with @thekaveman

[thekaveman]

Policy

Defines it like Provider does, with a top-level data key:

{
  "version": "x.y.z",
  "updated": 1570035222868,
  "data": {
     "policies": [ ... ]
  }
}

Suggest to change this to the same style as we are talking about here for Provider.

Jurisdiction

Defines it like Agency and Geographies, at the top-level (based on what is shown in the examples):

{
    "version": "1.2.0",
    "updated": "1570035222868",
    "end_date": "1570035222868",
    "jurisdictions": [ ... ]
}

This is the style we should align Provider and Policy to.

Metrics

Everything is at the top-level and the response format is pretty different from other MDS APIs.

No need to change anything here.

[thekaveman]

This is being handled for Provider in OpenAPI in openmobilityfoundation/mds-openapi#5

[schnuerle]

I will work to make this change in the MDS spec.

[schnuerle]

Fixed this by removing the data level across Provider and Policy in this commit. Can close this issue upon @thekaveman review.

[thekaveman]

Yep looks good 👍