-
-
Save sebilasse/0be1692bad2ef32214fbd220fac80e13 to your computer and use it in GitHub Desktop.
/* | |
Question: GET parameters OR POST body are validated with LDO#schema - | |
but how to validate (RFC 6570) URI template variables in the path ? | |
1) Path variables must be unique ("exclusive from params|body"). | |
They could then be mixed in the params|body and validated via LDO#schema as well | |
2) Heroku seems to make use of parantheses in URI templates to validate the variales | |
RFC 6570 : "The expression syntax specifically excludes use of the dollar ("$") and parentheses ["(" and ")"] characters | |
so that they remain available for use outside the scope of this specification." :: | |
*/ | |
{ | |
"description": "Mark an add-on as provisioned for use.", | |
"href": "/addons/{(%23%2Fdefinitions%2Faddon%2Fdefinitions%2Fidentity)}/actions/provision", | |
"method": "POST", | |
"rel": "create", | |
"title": "Create - Provision" | |
} |
Yes, got that. Thankyou.
To ask your question first: If we would implement it within curly braces, the router would make different routes if
the values in the parentheses are different, so it would fall through and go the second. And if that does not match it could send a 400
if validation was involved or a 404 if nothing matched at all.
Technically my router is translating the JSON Schema syntax to express syntax and when a route is matched by express, it does a coercive validation with the LDO and delivers the converted values.
However - in my opinion each route should match exactly one schema
and so in general I would expect the URL parameters to be validated in the schema
of the LDO :
"href": "/addons{/identity}/actions/provision"
This would match the express.js logic.
But the :variableName must not be used as query or body root then because all end in one object – example using dojo2 ...
lang.mixin( req.ldo.fromUri(req.url), (req.body||{}) );
In general I can't find any information in the specs. about how to validate URL parameters in LDOs so let's also respectfully ping the inventors
@fge , @kriszyp, @geraintluff
@sebilasse
So unfortunately Committee is currently pretty dumb about this. It acknowledges that there might be something between those curly braces, but doesn't try to do any sort of validation. Here's the implementation.
I think one problem that you'd run into with validating these is that it's really clear whether an invalid path should be a bad request or a 404. For example, if you have these two links:
GET /addons/{reference to schema requiring numeric string}
GET /addons/{reference to other schema}
And someone requests
GET /addons/abc
, would the validator give the user a 400 because we failed the first schema validation, or would that be expected to fall through and go the second?But yes, I guess my recommendation would be to keep those only loosely validated without a schema, but I do see how that could be inconsistent.