Repeatable URL parameters

[petrochenko-pavel-a]

Some APIs allows infinite nesting of URL parameter. As a canonical sample lets imagine API reprenting information about hierarchical file system and less use url parameters to represent structure of parent folders. Currently I see no good way to represent this pattern in the raml.

The possible way to solve it is to specify that resource path segments that are fully represented by URL parameter and has some special symbol at the end of the pattern (for example +) may be indefinitely repeated.

/files/{folderId+}/{fileId}
   get:
     .....

Regards, Pavel

[freddrake]

I have a use for something like this.

If the type of the repeatable parameter is an array of something that can be in a uriParameter, that seems sufficient, given language in the RAML spec that provides this interpretation. API specifications that use this would be more readable with an annotation as you describe, with * and + as allowable modifiers.

Being more specific in the type would allow additional constraints to be applied:

types:
   segment:
      type: string
      pattern: "[a-z][a-z0-9]*"

/files/{folderId+}/{fileId}:
   uriParameters:
      folderId:
        type: segment[]
        minLength: 1
        maxLength: 7
   get:
     .....

[petrochenko-pavel-a]

Yep

[freddrake]

A refinement: including * or + at the end of the uri parameter name in the resource entry should be required when the type is an array, and should match in number. (* if an empty array is allowed, + if not.) More elaborate RE-like notations should not be allowed:

/files/{folderId{1,5}}/{fileId}:
  ...

would be unreadable.

[jypma]

Is RAML still being extended? OpenAPI is also lacking a "Repeated path parameters" feature, and it would be nice to see it added to either spec :-)