Thanks for the review, Yonik.
It seems like there are multiple use-cases for the fields API...
One just wants to get all the info/properties for a field, and they don't care how that field is defined.
For example, they may want to look up field X to see if it's indexed, w/o having to worry about if it's a "dynamic" field or not.
I originally had code to do index lookup, but this API is about the schema, so I took it out, thinking that index queries didn't belong.
allowing the fields API to be used for dynamic fields also, but provide an indicator about what pattern matched
In my current state I do have an "includeDynamic" query param for the /schema/fields/fieldname request, to report the matching dynamic field properties if fieldname isn't an explicitly declared field.
One wants to get the actual definition definition in the schema (or as close to that as possible), and they would expect to see something very close to what they defined (or sent in using the fields API to create a new field). Showing all possible field properties like "storeOffsetsWithPositions" are going to be potentially confusing since people won't know what they mean and when/why they have to specify them when creating new fields.
only returning non-default properties... so if you create an integer field with "indexed=true", that's pretty much all you get back.
having a parameter to allow requesting all "look through" properties.
Good idea, I'll do this.
We should aim for being able to hit any node in the cluster w/o worrying about which nodes are hosting which collections.
Skimming Mark's patch modifying SolrDispatchFilter, I think the schema REST requests will already be proxied, but I'll test to be sure.
We should probably also default to indented JSON output.
OK, I'll switch to that.