Updated Proposed change to the model attribute #38
Conversation
The model, template and sending attributes have a potential to contradict each other. Trying to sort out the interdependencies between these three, I want to propose this change. Even if this proposal is not accepted, I think the relationship between these three attributes needs to be explicitly clarified and I hope my (quite radical) proposal helps us to see which contradictions can happen :)
If I am not mistaken, the only UriTemplate which expresses a form-urlencoded POST body is a level 1 template in the form name={value}&name={value}. At least I see no higher level template which expands to a form-urlencoded request body. A model of {givenName, familyName, hatSize} does not expand to a form-urlencoded body but to "Mark, Foster, Medium". {?givenName, familyName, hatSize} expands to something with a leading '?' and {&givenName, familyName, hatSize} to something with a leading '&'.
But if the model would always have to write out a full form-urlencoded body with variables anyway, we do not gain much by the model attribute as a mini-template. What is really only needed are the field names which are expected by the server in a PUT or POST. So I would like to propose this change.
Another point for this is the mime type of a request which is built from the model attribute (here: form-urlencoded by default). If the model does not expand to form-urlencoded, the data item would have to say so in the sending attribute. To deviate from form-urlencoded would only work with something similarly simple like text/plain, more complex requests cannot really be templated by the model attribute but require a template body anyway. So why have a mini-template in model and a full-blown template at the same time?
So I would like to propose to restrict the model to be the field name list for form-urlencoded only. The template constraints can describe valid values for the field names, the template body is for advanced request types.
|
pretty sure this is what appears in the proposed templates doc, right? all URIs are RFC6570 templates [1] what do you have above that is different? [1] https://rawgit.com/mamund/media-types/template-proposal/proposals/uber-templates-mca.html#_change_the_tt_url_tt_property |
|
not sure if you saw the actuall pull request. My proposal is to change model not to be a uritemplate but a simple list of field names which should appear in a form-urlencoded request. If the request is not form-urlencoded, a template should say what exactly is expected. Reason: model is too weak to be used as template for most formats other than form-urlencoded. For form-urlencoded it is not necessary to write out a body template in model, rather the field names seem sufficient. Is the difference more clear now? |
|
...assuming that the fieldname is also the variable name as in personid={personid}&city={city}. For cases where the server would expect something like p={personid}&c={city}, one could still use a template instead of a model |
|
IMO, it is overkill to REQUIRE the use of I also think it it wise to allow path-style segment and parameter expansion via the What would be good reasons to NOT allow the above? |
|
Mike, Or, to put it differently, if model is a uritemplate, it easily competes with the mimetype defined by sending. There are certainly many ways to solve this. My proposal is a bit radical by redefining model in such a way that it is not possible to define something legal in model which contradicts the sending mimetype. Best regards, ---- Mike Amundsen schrieb ----
|
|
again, we're on the same page, just working out how to get to the end. TBH, specs can only encourage or discourage behavior. we're on the Internet now on to the specifics... "if model is a uritemplate, it easily competes with the mimetype defined by "redefining model in such a way that it is not possible to define something it boils down to this:
mamund On Thu, May 8, 2014 at 12:03 PM, Dietrich Schulten <[email protected]
|
The model, template and sending attributes have a potential to contradict each other. Trying to sort out the interdependencies between these three, I want to propose this change. Even if this proposal is not accepted, I think the relationship between these three attributes needs to be explicitly clarified and I hope my (quite radical) proposal helps us to see which contradictions can happen :)
If I am not mistaken, the only UriTemplate which expresses a form-urlencoded POST body is a level 1 template in the form name={value}&name={value}. At least I see no higher level template which expands to a form-urlencoded request body. A model of {givenName, familyName, hatSize} does not expand to a form-urlencoded body but to "Mark, Foster, Medium". {?givenName, familyName, hatSize} expands to something with a leading '?' and {&givenName, familyName, hatSize} to something with a leading '&'.
But if the model would always have to write out a full form-urlencoded body with variables anyway, we do not gain much by the model attribute as a mini-template. What is really only needed are the field names which are expected by the server in a PUT or POST. So I would like to propose this change.
Another point for this is the mime type of a request which is built from the model attribute (here: form-urlencoded by default). If the model does not expand to form-urlencoded, the data item would have to say so in the sending attribute. To deviate from form-urlencoded would only work with something similarly simple like text/plain, more complex requests cannot really be templated by the model attribute but require a template body anyway. So why have a mini-template in model and a full-blown template at the same time?
So I would like to propose to restrict the model to be the field name list for form-urlencoded only. The template constraints can describe valid values for the field names, the template body is for advanced request types.