FEAT: add a pathTemplate option to cope with different uri path schemes

[pfurini]

Ref: #176 (comment)

Proposal

Add a pathTemplate property to Rest with a default of '${resource}/${id}', that is used to build the actual url to fetch. The property must be added at the end of the ctor as optional.
Please note this isn't an ES6 template string, the ${resource} and ${id} will be simply substituted with the first two parameters of various Rest methods (either resource and id, or resource and criteria).
Also add a new setDefaultPathTemplate() method to the config, that must be called prior to registerEndpoint to set a custom default for all endpoints (in a field like defaultPathTemplate, passed as the last parameter to the Rest ctor).

Things to consider:

• the join method in aurelia-path will not be used anymore, and it is simply a user's responsibility to pass sensible parameters with proper slashes. No assumptions could be made on the contents of the pathTemplate property.
• the hasSlash hack must be removed for this to work properly (already logged as #146)

Benefits

One could use that property to talk to an API that expects resource paths in other formats, like OData style:
'${resource}(${id})' -> path(id)

[pfurini]

After more thinking about it, I'd add a restOptions parameter to registerEndpoint, that the user could use to change the pathTemplate of that specific Rest instance (and the useTraditionalUriTemplates flag of my other PR).
It's not so uncommon to have different APIs for different micro-services, that are baked my completely different technologies, so it makes sense having the ability to tweak the settings on an individual base..

[doktordirk]

yeah, needs to be allways on endpoint basis. eg the authentication provider could be completely different

[pfurini]

Don't know if the removal of hard-coded join and the slash hack could be a potential BC for consumers..
What do u think?

[doktordirk]

i don't as such care to much about the slash hack. it should be solved on serverside. but making a 4.0 would be fine

• add a Date object parsing option

[pfurini]

add a Date object parsing option

What do you mean?

[doktordirk]

aurelia-path converts criteria as {date: new Date} to "" instead of eg date=1.1.1970

[pfurini]

@doktordirk ah ok, but it's out of this issue's scope.. and it's not an easy one either

Maybe open another issue if you wish, but Date conversion is a pretty subtle task in JS as you surely know. IMHO it's better to stick with that conversion pre-api call, when one can use mature libraries like momentjs and it's companion moment-timezone (that's what I do in every project, never touch a date conversion without my good old friend moment ;)

[zeko77]

PathTemplate via restOptions would be neat.

[RWOverdijk]

@zeko77 It would It's now resource based, but making that configurable is absolutely a cool idea. PRs are welcome!

[RWOverdijk]

Closing this for now. If this is still relevant, feel free to reopen the issue.

Note: this is a copy-paste comment to clean up the issues. It's not personal, and I didn't review the issue before posting this. They're all outdated and I need a way to figure out what's still relevant.

Thank you for understanding :)