jpsider/RestPS

Proposal for variable routes

Opened this issue · 2 comments

anddave commented

Proposal for variable routes

  • As of RestPS 7.0.44 from PSGallery, only hardcoded routes are supported, which is to say that Invoke-RequestRouter selects routes where {$_.RequestURL -eq $RequestURL}.
  • Consequently endpoints like "api/periodictable/{element}" are marginally feasible in small scale only and not feasible in large scale.
  • Proposal: we could add a regex match to Invoke-RequestRouter which would enable variable routes.
  • For the sake of simplicity, I propose that:
    • Map file should only be changed to support regex matching
    • as opposed to adding any more notational load to the map file, let the endpoint scripts do all the interpreting of variable routes beyond matching the regex.
  • Some defensive code and unit testing may need to be added for mitigating the risk of accidental route doubling if a route is both an exact match and a regex match.
  • Branch and PR forthcoming soon
    Thanks @jpsider great module
jpsider commented

Makes sense. I have not had the need to add this up to this point. But in dealing with other API's use this type of thing on a normal basis. I am looking forward to reviewing the PR!

anddave commented

This is what it looks like when multiple routes match

INFO: Start-RestPSListener: Processing RequestType: GET URL: /periodictable Args:
/RestPS/RestPS/private/Invoke-RequestRouter.ps1:58
Line |
58 | $CommandReturn = . $RequestCommand -RequestArgs $RequestA …
| ~~~~~~~~~~~~~~~
| The term
| '/periodictable/endpoints/GET/Invoke-EndpointPeriodicTable.ps1
| /periodictable/endpoints/GET/Invoke-EndpointPeriodicTable.ps1'
| is not recognized as a name of a cmdlet, function, script
| file, or executable program. Check the spelling of the name,
| or if a path was included, verify that the path is correct and
| try again.