Restrict Resource output to string-keyed collections

[bennostein]

The default REST server implementation passes HTTP path parameters straight through to Skip, which caused me a bit of confusion when resources have non-string keys.

We may avoid putting key parameters straight into the path in the future, but for now this prevents the confusion I ran into (i.e. requesting a path like /users/1 and getting nothing because the user is keyed on the number 1 and not the string "1")

[jberdine]

Question: would changing from GET to POST a la #535, which would put the resources and params into the request body as json instead of being encoded in the URL, have avoided the original confusion?

[bennostein]

Question: would changing from GET to POST a la #535, which would put the resources and params into the request body as json instead of being encoded in the URL, have avoided the original confusion?

As I understand it, yes! Lucas mentioned (offline) wanting to do that at some point too, and in particular emphasizing that a sync read instantiates a resource, which could be misunderstood under the current scheme where the key is a path parameter.

[jberdine]

Question: would changing from GET to POST a la #535, which would put the resources and params into the request body as json instead of being encoded in the URL, have avoided the original confusion?

As I understand it, yes! Lucas mentioned (offline) wanting to do that at some point too, and in particular emphasizing that a sync read instantiates a resource, which could be misunderstood under the current scheme where the key is a path parameter.

Ok good. This makes me wonder if we should make the POST change instead of reducing the generality of the key type.

[bennostein]

Seems reasonable to me. I'll table this for the time being, but still going to keep working on docs-writing, not implement that POST change.