MapsTo ideas from Hyperdescribe discussion

[fosdev]

Three things to ensure we address:

1. Hyperdescribe ability to map to a different attribute (?q}, but have "query" as the name of the field, e.g. ?q={query}
2. Scope of applicability (uri template, body, both, neither)
3. Instructions for PUT related/replace related endpoints that instructs a client to build the complete resource and send it without overloading "required" constraint/validators. Is there use for a hidden field concept? E.g. field you cannot update that is set/generated by service. Is that part of the resource you are replacing?

[smizell]

Just perusing this repo and saw this issue and thought I'd add a note on item 3 and the hidden fields. In Hyperdescribe, I was toying with this idea of immutability of form fields. I am not sure I really accomplished my goal (one of the many reasons I'm not at 1.0 for Hyperdescribe), but I used a couple of values:

• defaultValue - This was a hint at what the default value for the field is. This allowed me to set a field as required and give a default value, or even treat a field somewhat like a <select> and set one of the options as selected.
• value - This is the value of the field, and if set, is considered immutable. This means that I could add a CSRF token much like Rails does and the client would treat like a hidden field.

Then there is mapsTo, which also (sort of) allows me to specify what the current value of the field/parameter is.

Just some thoughts. Might not fit, but maybe it will spark some ideas!

[sheavalentine-mdsol]

Currently you emulate a hidden field by specifying {"required": true, "value": "CRF_token"} - it is sufficient (though perhaps not optimal) for #3. #2 does need further investigation. Is #1 allowed already by the URL Template spec?