Don't use GET bodies for query parameters about mobility-data-specification

[asadowns]

I would say moving the request parameters into a query string is probably the correct approach here.
I don't believe there is the need for complex geometric shapes if the base geometry for the particular MDS client is provided as part of the token based auth.
Using a POST to retrieve data is often considered to be not semantic.

I would recommend keeping /trips and /status_changes as GET and clarifying around query parameters. I provided a potential approach in #64.

On the agency side I think it may be a bit early to deciding if service_areas need support for specific provider_id or an additional /:id route. I think both of these are good ideas to keep in mind moving forward but I don't think there should necessarily be an update now without a use case.

Let me know what you think!

[migurski]

GET parameters is the right spot for this. Would you be comfortable documenting these using RFC6570-compliant form-style query expansion?

Example: /service_areas{?provider_id}{?service_area_id}.

[thekaveman]

I think part of the confusion is, these query parameters aren't spelled out anywhere in the spec yet. But I also don't see where it is stated that MDS is expecting GET request bodies? That sounds crazy, I totally agree it is a bad idea @oderby!

I also tend to agree with @asadowns and @migurski here, these are very clearly GET requests (read-only, should be idempotent given the same parameters, etc.). @asadowns did some initial work on defining the query params over on #64 - can we move this discussion to that proposal so we can comment on some actual changes to the language in the spec?

(BTW I also really like the suggestion of tying the geo-area to the auth token (see #60) from @asadowns, thus obviating the need for that data on every request.)

I'm closing this one to hopefully move the discussion over to these ongoing threads. Thanks!