"Type can be either of: string, number, integer, file, date or boolean"


We have developed an engine that combines a RAML API definition along with some reflection on the backend which allows us to dynamically link/expose platform services as APIs as defined in the RAML ‘contract’

All is well :slight_smile: except for one little (big) headache.

Uri/Query Parameters are restricted to the above types whereas i need to have any number of custom types. An example is for say CardNumbers i’d define a “cardnumber” type - which would save me a some work on the backend in terms of conversion, !logging etc.

Why is this check in place? is there any way to remove it? or at least extend the valid set of types?


Hi @kurtparis,
As you mentioned, Query/Uri Parameters are restricted to the basics datatypes.
For the case you are describing, a CardNumber is just a String. If you wanted to apply a validation to it (that could be handled at API level) I would recommend you using “Patterns” (http://raml.org/spec.html)


(Optional, applicable only for parameters of type string) The pattern
attribute is a regular expression that a parameter of type string MUST
match. Regular expressions MUST follow the regular expression
specification from ECMA 262/Perl 5. The pattern MAY be enclosed in
double quotes for readability and clarity.

Does it make sense?
Best Regards.


patterns are great and we are using them to get “free” string/format/structural validation using the framework we developed (or any other validator for that matter)

However they do not allow you to define semantics or typing.

As an example we encode ids to important object into an abject we call a reference. Essentially this is a Base64/URL encoded string. On the back end i have to know (and code in) semantics that parameter X is of this type. If this were possible to define in the RAML doc, my backend could infer this from the type. (which is in fact what we are doing for JSON body parameters)

At this stage what is a bit of a killer for me is that the api tooling is throwing a hissy fit when it finds something other than the types it expects.

An option could be to include the option of extensions. so say this reference could be defined as an extension of type string - which would allow the tooling to work on the expected subset