Closed SteveCookTU closed 2 years ago
I agree, that'd be a great improvement ! However, I'm not sure exposing a function that directly calls the API is a good solution. The goal of a wrapping library is to serve and facilitate the use of the underlying resource. Letting the user manage urls isn't a good approch imo...
Maybe the targeted resource that can be lazy fetched ? Or a function that can parse the url to retrieve the name or the id ?
What do you think about that ?
Or a function that can parse the url to retrieve the name or the id ?
This was my first thought, sort of like an internal utility function which would be the safest option. I agree directly calling the API from an exposed function wouldn't be the way to go.
I also like the idea of lazy fetching the extra resources though so extra endpoint calls wouldn't be necessary for a user and code-flow would probably be more optimal/readable. With that in mind, I'm not sure it would be a bad idea for both solutions to be implemented.
I agree ! To be honest, the lazy fetching would be soooo elegant, but way more complex to implement.
What do you think? Are you interested trying to implement something?
If I find time I could attempt to create an implementation. Got a little busy after I found this project.
I just merged the feature that will allow to follow NamedApiResource (along with some modifications). I'll release the v2.0.0 right away !
Feel free to test it and send me some feedback if you want to !
Thanks again for the issue, this is indeed a nice to have feature :)
I was thinking it would be a useful feature to be able to call an endpoint for a Url in a NamedApiResource. Say I want to go from an encounter to version group, as of right now the ID has to be taken from Url string and passed to another endpoint function.